f



Becoming a Macintosh Programming Guru [C++ & how?]

Hello All,

I'm interested in becoming the best damn source of info in my group
for Macintosh programming questions.

What would you reccommend? Please, no Cocoa discussion as my company
is a cross-platform company and our programmers are primarily Windows
people. I admit that it may be a great way to develop apps on the Mac,
but it is not an option here.

I'm a 85% Mac/15% Win programmer at my company working with
networking, powerplant, preemptive threads, cross-platform classes,
etc.

I read the carbon discussion list trying to comb out the useful info
for my company as well as the headlines of these newsgroups
(comp.sys.mac.programmer.*).

I look at macdevcenter once and a while and I do not see a lot of
activity - I'm thinking of subscribing to mactech as well.

But, what do people reccommend? For "Mac" books I have the Carbon
Programming book, The Ultimate Mac Programming book (circa 1995), Mac
Programming FAQs, Codewarrior books, PowerPlant books, as well as
other non-mac programming books.

Anyway, hopefully I can generate some discussion that will help others
as well.

Thanks,
Lyndsey
0
lyndsey_ferguson
11/11/2003 4:24:52 PM
comp.sys.mac.programmer.help 4653 articles. 2 followers. Post Follow

108 Replies
559 Views

Similar Articles

[PageSpeed] 22

In article <edc42e1f.0311110824.5aa84ad1@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:
> I'm interested in becoming the best damn source of info in my group
> for Macintosh programming questions.
> 
> What would you reccommend? 

One method that I've regularly used for the past 16.5 years is to make 
sure I read all of the Tech Notes.  These provide not only information 
about solving particular problems, but often insight into less obvious 
areas of the OS and how they can be brought to bear on problems.

I can't tell you the number of times I read something in a Tech Note and 
then less than a month later it was the exact solution I needed!

Apple developer web site now has a Tech Note and Q&A "What's New" 
section.  I check them both at least once a month:
<http://developer.apple.com/technotes/indexes/whatsnew0.html>
<http://developer.apple.com/qa/indexes/whatsnew0.html>

At the same time, I also check the main sample code page for new or 
newly revised sample code that might be of interest:
<http://developer.apple.com/samplecode/>

Even as an "insider" at Apple, these notes often distill the information 
in such a way it is easy for a novice in a particular area to get 
started.  Joe Bob says check 'em out!
0
Tom
11/11/2003 5:11:52 PM
In article <edc42e1f.0311110824.5aa84ad1@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> I'm interested in becoming the best damn source of info in my group
> for Macintosh programming questions.
> 
> What would you reccommend? 

I recommend you do what I do :-D

Seriously, my knowledge comes from:

1. Keeping up on technotes and Q&As
2. Reading most questions and answers on this NG (and related groups), even if I 
only answer a few.
3. Keeping up on Apple's documentation (I try to skim everything, so that I at 
least know where to look for answers when answers are needed)
4. Reading all CW release notes
5. Writing code
6. Reading all the top-notch C++ books I can lay my hands on and applying them 
to what I do

I don't read the Carbon list regularly, as it is high-volume, but I am 
subscribed to it and look at the subject lines from time to time to see if 
there's anything interesting going on.

> I look at macdevcenter once and a while and I do not see a lot of
> activity - I'm thinking of subscribing to mactech as well.

MacTech is not as useful as you might think, but the subscription is not that 
expensive, so you can pay for a year and see how you like it (or you can look at 
the archives).

I learned a lot by going to MacHack in the past. 

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
11/11/2003 5:26:10 PM
dans l'article edc42e1f.0311110824.5aa84ad1@posting.google.com, Lyndsey
Ferguson � lyndsey_ferguson@yahoo.com a �crit le 11/11/03 17:24�:

> What would you reccommend? Please, no Cocoa discussion as my company
> is a cross-platform company and our programmers are primarily Windows
> people. I admit that it may be a great way to develop apps on the Mac,
> but it is not an option here.

Is this because Cocoa requires Objective-C ? If it is, it's interesting to
see that I'm not the only one in this group to think that Objective-C slows
down Cocoa adoption, especially in a multiplatform context.

Eric

0
Eric
11/11/2003 5:36:24 PM
In article <BBD6DCA8.151AC%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Is this because Cocoa requires Objective-C ? If it is, it's interesting to
> see that I'm not the only one in this group to think that Objective-C slows
> down Cocoa adoption, especially in a multiplatform context.
> 
> Eric

This is ridiculous...the point is that the Cocoa API would have to be 
replicated on other platforms, and its not...whereas, for instance, 
PowerPlant does replicate a similar API on Mac and Windows.

Let's face it, Cocoa is easy because there are so many convenience 
functions...Obj-C or Java help prevent errors, but the API is what helps 
developers get a lot done in a little bit of code.

-- 
|\/|  /|  |2  |<
mehaase(at)sas(dot)upenn(dot)edu
0
Mark
11/11/2003 8:29:20 PM
In article <mehaase-BF848D.15291911112003@netnews.upenn.edu>,
 Mark Haase <mehaase@earthlink.net> wrote:
> This is ridiculous...the point is that the Cocoa API would have to be 
> replicated on other platforms, and its not...whereas, for instance, 
> PowerPlant does replicate a similar API on Mac and Windows.

Yep, and if you aren't using a "cross platform" framework then you are 
going to have to develop your own best way to deal with your UI/event 
code on the two platforms.

In a similar way, MFC/COM is likewise a pretty difficult match going 
from Windows->Mac.

Applications that make heavy use of MFC/COM for their UI, but have a 
large core of raw C/C++ would probably move easiest/fastest/best by 
factoring the UI from the core as much as possible and using MFC on 
Windows and Cocoa on the Mac side.

Applications with less of an MFC bent will probably find Carbon and its 
event model a good impedance match to Windows and its event handling.
0
Tom
11/11/2003 9:16:31 PM
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote in message news:<BBD6DCA8.151AC%eric.vergnaud@wanadoo.fr>...
> dans l'article edc42e1f.0311110824.5aa84ad1@posting.google.com, Lyndsey
> Ferguson � lyndsey_ferguson@yahoo.com a �crit le 11/11/03 17:24 :
> 
> > What would you reccommend? Please, no Cocoa discussion as my company
> > is a cross-platform company and our programmers are primarily Windows
> > people. I admit that it may be a great way to develop apps on the Mac,
> > but it is not an option here.
> 
> Is this because Cocoa requires Objective-C ? If it is, it's interesting to
> see that I'm not the only one in this group to think that Objective-C slows
> down Cocoa adoption, especially in a multiplatform context.

Yes, I can say that learning an additional language is an obstacle.  I
consider the attitude of many of our Windows programmers to be quite
reluctant to do Macintosh programming.  I used to be the same when it
was necessary for me to write Windows code - but now I love being able
to write cross-platform code.

If these programmers are forced to learn an additonal language - they
are going to do a bad job of the implementation because they are going
to be throwing it together haphazardly.  If our shop is a C++ shop and
the core of our app is written using C++ as well as the Windows side
and currently the Macintosh side, it seems to me to be like throwing a
wrench into the machine if you force Objective-C on the  Macintosh. 
We do not have an even team of Mac/Win programmers, we have
programmers who have percentages of work that they do on both
platforms.

Lyndsey
0
lyndsey_ferguson
11/12/2003 2:17:45 PM
Thanks Tom & Miro,

I also read the latest ADC news looking for new documentation to read.
 What about any new "must have" books? I have bookmarked the technical
notes page and the sample code page and plan to make that a stopping
point as well.

Lyndsey
0
lyndsey_ferguson
11/12/2003 2:21:57 PM
In article <BBD6DCA8.151AC%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Is this because Cocoa requires Objective-C ?

Cocoa has a Java API as well.  Unfortunately.

> If it is, it's interesting to
> see that I'm not the only one in this group to think that Objective-C slows
> down Cocoa adoption, especially in a multiplatform context.

Cocoa adoption is slowed down only by stupid developers.  They make 
choice not based on technical merit, but on what everyone else is using.  
Widespread adoption of C++, a completely crap OO language, hurts far 
more than it helps.  That Apple felt a need to add Java, a merely bad OO 
language, support to Cocoa (and cripple WebObjects by going Java-only) 
is evidence they recognize this sad state of affairs.  ObjC does just 
fine on multiple platform, and much of Cocoa is implemented by GNUstep.  
Anyone who blames ObjC, a most *minor* of extensions to give C OO 
support, for anything needs to first look at their own OO skills and 
their own corporate mono-language structure.
0
Doc
11/12/2003 3:40:23 PM
dans l'article droleary.usenet-30CB12.09402312112003@corp.supernews.com, Doc
O'Leary � droleary.usenet@subsume.com a �crit le 12/11/03 16:40�:

> In article <BBD6DCA8.151AC%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> Is this because Cocoa requires Objective-C ?
> 
> Cocoa has a Java API as well.  Unfortunately.
> 
>> If it is, it's interesting to
>> see that I'm not the only one in this group to think that Objective-C slows
>> down Cocoa adoption, especially in a multiplatform context.
> 
> Cocoa adoption is slowed down only by stupid developers.  They make
> choice not based on technical merit, but on what everyone else is using.
> Widespread adoption of C++, a completely crap OO language, hurts far
> more than it helps.  That Apple felt a need to add Java, a merely bad OO
> language, support to Cocoa (and cripple WebObjects by going Java-only)
> is evidence they recognize this sad state of affairs.  ObjC does just
> fine on multiple platform, and much of Cocoa is implemented by GNUstep.
> Anyone who blames ObjC, a most *minor* of extensions to give C OO
> support, for anything needs to first look at their own OO skills and
> their own corporate mono-language structure.

I should have known this was a guru-driven list.

Some show up, like Doc, others hide, saying facts are not facts.

Good luck !

Eric

0
Eric
11/12/2003 4:22:00 PM
In article <edc42e1f.0311120617.1f44fd28@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> Yes, I can say that learning an additional language is an obstacle.  I
> consider the attitude of many of our Windows programmers to be quite
> reluctant to do Macintosh programming.  I used to be the same when it
> was necessary for me to write Windows code - but now I love being able
> to write cross-platform code.
> 
> If these programmers are forced to learn an additonal language - they
> are going to do a bad job of the implementation because they are going
> to be throwing it together haphazardly.  If our shop is a C++ shop and
> the core of our app is written using C++ as well as the Windows side
> and currently the Macintosh side, it seems to me to be like throwing a
> wrench into the machine if you force Objective-C on the  Macintosh. 
> We do not have an even team of Mac/Win programmers, we have
> programmers who have percentages of work that they do on both
> platforms.

Are you aware of Apple's Objective-C++ compiler, which allows you to mix 
Objective-C and C++ code? This is used, for example, in Apple's WebCore, 
which wraps KHTML in ObjC code to make it available for Cocoa programs.

ObjC the language is extremely simple. It consists of about ten extra 
keywords on top of C, and if you're already familiar with C++ it should 
go very quickly since you're already familiar with a lot of OO concepts. 
Of course you may not start producing very good code right away. But 
only your code which talks to Cocoa has to be ObjC, the rest can be C++ 
without any trouble. I have not personally used the ObjC++ compiler for 
anything beyond very small projects, but it seems to work very well.

So, I think ObjC ought not to be an obstacle, although you will have 
your own opinion, of course. And Carbon's API may be more suitable to 
you anyway, given its similarity with Win32.
0
Michael
11/12/2003 4:34:04 PM
In article <droleary.usenet-30CB12.09402312112003@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> Cocoa has a Java API as well.  Unfortunately.

Why is this unfortunate? I say, the more languages the merrier! Do you 
also lament the existance of PyObjC and all of the other language 
bridges out there? Nobody's forcing you to use any of them.
0
Michael
11/12/2003 4:36:13 PM
Lindsey,

As a matter of fact, it is feasible to connect a C++ framework to Obj-C
Cocoa. I've just done it. It's not complete yet, but it's 100% Cocoa, it
works, with only 6000 lines of Obj-C code, and follows the architecture
described in Apple's CocoaInCarbon samples (although I'm using CW 8.3 to do
the job, and a static library for the Obj-C part, which I couldn't manage
with PB).

I strongly recommend using Cocoa, since the Cocoa UI framework is much
closer to Windows GDI than Carbon is, and much safer too IMHO. NSViews are
pretty much like HWNDs, and they handle all the necessary clipping etc...
when drawing, much better than HIViews do (their Carbon counterpart). I
handle all the drawing using Quartz in C, Quartz being the underlying
graphics engine of Cocoa, which is much more powerful than Quickdraw, and
more powerful than Win32 GDI. You can use Quartz with Carbon, but it's a
pain, since a huge part of Carbon was primarily designed for Quickdraw. So
the only Obj-C code I have is for Cocoa UI objects (windows and controls)
and threads.

But above all this, I'd say the event model is much easier to deal with for
Windows programmer, since it's a preemptive model rather than a polling
model like Carbon. For example, you don't need a mouse tracking loop in
Cocoa as you do in Carbon, your custom NSView simply receives a mouseDragged
message, very similar in concept to the WM_MOUSEMOVE message you get in a
HWND proc with a SetCapture.

If you can think of this job as creating a C library that handles the
C/Cocoa conversion, it's a one man's task, so other programmers won't have
to learn Obj-C to start with (although I strongly recommend that they do on
the long term).

Eric

>>> What would you reccommend? Please, no Cocoa discussion as my company
>>> is a cross-platform company and our programmers are primarily Windows
>>> people. I admit that it may be a great way to develop apps on the Mac,
>>> but it is not an option here.
>> 
>> Is this because Cocoa requires Objective-C ? If it is, it's interesting to
>> see that I'm not the only one in this group to think that Objective-C slows
>> down Cocoa adoption, especially in a multiplatform context.
> 
> Yes, I can say that learning an additional language is an obstacle.  I
> consider the attitude of many of our Windows programmers to be quite
> reluctant to do Macintosh programming.  I used to be the same when it
> was necessary for me to write Windows code - but now I love being able
> to write cross-platform code.
> 
> If these programmers are forced to learn an additonal language - they
> are going to do a bad job of the implementation because they are going
> to be throwing it together haphazardly.  If our shop is a C++ shop and
> the core of our app is written using C++ as well as the Windows side
> and currently the Macintosh side, it seems to me to be like throwing a
> wrench into the machine if you force Objective-C on the  Macintosh.
> We do not have an even team of Mac/Win programmers, we have
> programmers who have percentages of work that they do on both
> platforms.
> 
> Lyndsey

0
Eric
11/12/2003 4:49:23 PM
In article <droleary.usenet-30CB12.09402312112003@corp.supernews.com>,
 Doc O'Leary <droleary.usenet@subsume.com> wrote:

> Cocoa adoption is slowed down only by stupid developers.  

But worry not -- sage advice from Doc O'Leary will counteract all that stupidity.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
11/12/2003 5:27:21 PM
In article <edc42e1f.0311120621.74141bcb@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> I also read the latest ADC news looking for new documentation to read.
>  What about any new "must have" books? I have bookmarked the technical
> notes page and the sample code page and plan to make that a stopping
> point as well.

In C++ and OOP land, there are a bunch of must-have books. I am not aware of any 
in Mac land.

Also, at some point you may become interested in learning stuff because it 
attracts you, rather than for the sole purpose of fending off incompetence and 
ignorance at work, in which case there are a bunch of books I consider essential 
to a well-educated software engineer. 

That's probably because Cocoa is designed so well that it doesn't need 
documentation, Carbon is dead so nobody needs it documented, and C++ is hard 
(let's go shopping) so it needs thick volumes of arcane lore. ;-)

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
11/12/2003 5:33:59 PM
In article <BBD82323.15263%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> But above all this, I'd say the event model is much easier to deal with for
> Windows programmer, since it's a preemptive model rather than a polling
> model like Carbon. For example, you don't need a mouse tracking loop in
> Cocoa as you do in Carbon, your custom NSView simply receives a mouseDragged
> message, very similar in concept to the WM_MOUSEMOVE message you get in a
> HWND proc with a SetCapture.

Carbon's event model is preemptive and doesn't use a mouse tracking loop.

You're thinking of WaitNextEvent loops, which are strongly discouraged 
for new code.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/12/2003 6:07:13 PM
dans l'article ejalbert-793272.10071312112003@news.stanford.edu, Eric Albert
� ejalbert@stanford.edu a �crit le 12/11/03 19:07�:

> In article <BBD82323.15263%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> But above all this, I'd say the event model is much easier to deal with for
>> Windows programmer, since it's a preemptive model rather than a polling
>> model like Carbon. For example, you don't need a mouse tracking loop in
>> Cocoa as you do in Carbon, your custom NSView simply receives a mouseDragged
>> message, very similar in concept to the WM_MOUSEMOVE message you get in a
>> HWND proc with a SetCapture.
> 
> Carbon's event model is preemptive and doesn't use a mouse tracking loop.
> 
> You're thinking of WaitNextEvent loops, which are strongly discouraged
> for new code.
> 
> -Eric

No, I'm thinking of TrackMouseLocation, which blocks your application, and
polls events until the mouse is released. I agree it's not a mouse tracking
loop from , but it's equivalent. And it's not preemptive.

Having dealt with this particular case in the opposite way (porting Mac code
to windows), I found that it leads to big differences in coding. The Cocoa
model is much closer to the Windows model.

Eric.

0
Eric
11/12/2003 7:06:24 PM
In article <BBD84340.1542E%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article ejalbert-793272.10071312112003@news.stanford.edu, Eric Albert
> � ejalbert@stanford.edu a �crit le 12/11/03 19:07�:
> 
> > In article <BBD82323.15263%eric.vergnaud@wanadoo.fr>,
> > Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> > 
> >> But above all this, I'd say the event model is much easier to deal 
> >> with for Windows programmer, since it's a preemptive model rather 
> >> than a polling model like Carbon. For example, you don't need a 
> >> mouse tracking loop in Cocoa as you do in Carbon, your custom 
> >> NSView simply receives a mouseDragged message, very similar in 
> >> concept to the WM_MOUSEMOVE message you get in a HWND proc with a 
> >> SetCapture.
> > 
> > Carbon's event model is preemptive and doesn't use a mouse tracking loop.
> > 
> > You're thinking of WaitNextEvent loops, which are strongly discouraged
> > for new code.

> No, I'm thinking of TrackMouseLocation, which blocks your application, and
> polls events until the mouse is released. I agree it's not a mouse tracking
> loop from , but it's equivalent. And it's not preemptive.

Well, a) you don't have to use it (it's just using regular Carbon 
events), b) it doesn't poll, and c) it doesn't block your application 
(you can still run timers, I think, and you might even get other 
events).  If all you want is a mouse dragged message, register for mouse 
dragged events.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/13/2003 7:07:21 AM
In article <ejalbert-736934.23072112112003@news.stanford.edu>,
 Eric Albert <ejalbert@stanford.edu> wrote:

> In article <BBD84340.1542E%eric.vergnaud@wanadoo.fr>,
>  Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
> > No, I'm thinking of TrackMouseLocation, which blocks your application, and
> > polls events until the mouse is released. I agree it's not a mouse tracking
> > loop from , but it's equivalent. And it's not preemptive.
> 
> Well, a) you don't have to use it (it's just using regular Carbon 
> events), b) it doesn't poll, and c) it doesn't block your application 

It does block the app -- until the next event or timer.

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
11/13/2003 8:35:54 AM
Doc O'Leary <droleary.usenet@subsume.com> wrote in message news:<droleary.usenet-30CB12.09402312112003@corp.supernews.com>...
> Cocoa adoption is slowed down only by stupid developers.  They make 
> choice not based on technical merit, but on what everyone else is using.

Being one of said stupid developers, [self jumpIn: quick flameSuit:
YES];.

Cocoa adoption is being slowed by a LOT of factors. Cococ/ObjC code
tends to be very verbose, and esoteric in comparison to all the other
environments that I've seen. Take string creation/manipulation using
NSStrings, vs STL strings in C++. Where's the operator overloading???
Even a stupid programmer like myself understands those instantly;
instead of having to spend time scouring the documentation to find how
to handle basic data types I could have been just getting on with my
program. Similarly, the concept of multiple inheritance is far more
intuitive than protocols.

(Indeed, the only other language I've ever struggled with to the same
degree - and I've learnt a lot  - is Prolog. And in the programming
landscape, that's in the "Here Be Dragons" territory.)

Then there's the documentation. Any good, thorough set of
documentation needs to include three things, a complete reference
(obviously), sample code (for those "ah, THAT'S what he meant" times),
and a detailed introduction & discussion. For Cocoa/ObjC, the first
two are fine, the latter is pretty sparse. 'If you want to bungie
jump, see NSBungieJump'. Cheers! At least the documentation is
improving.

Then there's the development tools. The Xcode & IB integration is
sorely lacking in comparison to the other options. If you're
prototyping (which is probably how most developers new to OSX or XCode
are going to dive in), you're probably going to find yourself going
back and forth between the two apps a lot. But there's no 'auto-sync':
I need to manually read the header files in IB, or make the changes in
IB and merge the changes back into the source, something I still
haven't been able to do. Then again, I am a stupid developer.

And look at this case: for the first time, I needed to create a button
with an icon. I looked in the Inspector, and it asked me for a string.
What string? A resource ID? File name? File path? Absolute or
relative? What file type? I looked through the documentation, and
found nothing. Google'd, nothing. Eventually, I found one of the
sample apps had icon buttons, and realised you needed to add a .tiff
file (are other formats supported?) to the project, then enter it's
case sensitive(???) name as the string. How very '80s.

[self rantShouldTerminate] ;

Mike.
0
google
11/13/2003 11:29:02 AM
In article <f7e883a5.0311130329.70d5f274@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Cocoa adoption is being slowed by a LOT of factors. Cococ/ObjC code
> tends to be very verbose, and esoteric in comparison to all the other
> environments that I've seen. Take string creation/manipulation using
> NSStrings, vs STL strings in C++. Where's the operator overloading???
> Even a stupid programmer like myself understands those instantly;

Until you try to concatenate two constant strings, "Hello " + "world!", 
doh! The equivalent in Cocoa works correctly, of course because it's a 
totally different thing. Of course, we can debate the merits of operator 
overloading until the sun goes out, but I can't see this being a major 
stumbling block to adoption; after all, many people come from C or other 
languages without operator overloading.

> instead of having to spend time scouring the documentation to find how
> to handle basic data types I could have been just getting on with my
> program.

For strings and similar 'basic' data types, I find the headers to be 
quick to examine and informative enough when looking for a way to do X, 
when I don't have a clue what the method would be called. But I'm pretty 
used to the system by now.

> Similarly, the concept of multiple inheritance is far more
> intuitive than protocols.

MI and protocols aren't the same thing at all. If you're referring to 
using MI to allow separate objects with no common parent to respond to 
the same messaging interface, ObjC handles that in a completely 
different manner (as I'm sure you know) in which protocols are only a 
very peripheral and unnecessary thing.

Certainly the messaging system is different and this will cause some 
adoption trouble. But there's really no way around that.

> (Indeed, the only other language I've ever struggled with to the same
> degree - and I've learnt a lot  - is Prolog. And in the programming
> landscape, that's in the "Here Be Dragons" territory.)

I found ObjC to be quite easy to learn, as have many others. I don't 
mean this as any slight against you, just a point of data. It seems to 
me that a great many people find it very easy, and some people find it 
very difficult for reasons that the rest of us don't understand. :) I 
was comfortable with the language itself in a day or two and producing 
useful code. Learning the class library I was using with it (Swarm, at 
the time) took much, much longer, since that's the actual complicated 
piece of the ObjC puzzle.

Of course, I also thought Prolog was fairly easy too, so I'm probably 
not a normal case. :)

> Then there's the documentation. Any good, thorough set of
> documentation needs to include three things, a complete reference
> (obviously), sample code (for those "ah, THAT'S what he meant" times),
> and a detailed introduction & discussion. For Cocoa/ObjC, the first
> two are fine, the latter is pretty sparse. 'If you want to bungie
> jump, see NSBungieJump'. Cheers! At least the documentation is
> improving.

I can certainly agree with this. Learning the language is easy enough, 
learning the APIs in a basic manner isn't too bad, but getting a general 
idea of how the system works as a whole takes quite a while, and is 
pretty necessary. I did this the hard way, by just slogging through and 
having to go back and rewrite stuff that ended up not being very good. 
Probably the tutorials out there would help, but I never had the 
patience to try any of them. Cocoa displays a lot of emergent behavior. 
The components are simple, but the behavior of the whole is complex.

> Then there's the development tools. The Xcode & IB integration is
> sorely lacking in comparison to the other options.

Are you referring to other options on the Mac, and if so, what are they?

> If you're
> prototyping (which is probably how most developers new to OSX or XCode
> are going to dive in), you're probably going to find yourself going
> back and forth between the two apps a lot. But there's no 'auto-sync':
> I need to manually read the header files in IB, or make the changes in
> IB and merge the changes back into the source, something I still
> haven't been able to do.

This can be done less painfully by taking advantage of drag-and-drop; 
once you've changed a header in Xcode, just drag the file from your 
project window or the file's window title bar into your nib's main 
window in IB, and everything gets read. It would be nice to have this be 
a little more automatic, but it doesn't seem too bad to me. I don't have 
much experience with any other framework comparable to Cocoa, though.

> Then again, I am a stupid developer.

Aren't we all? :)

> And look at this case: for the first time, I needed to create a button
> with an icon.

You do have to add it to your project, because nibs can't contain 
images. (Or rather, they can, but they shouldn't. No, I don't know why.) 
But once you've done that, you can just go to the Images tab of your 
main nib window and drag the appropriate image onto your button. Drag 
and drop to the rescue again.

Of course, it took me about a year to realize this shortcut. Before 
that, I was typing in the filenames just like you, without a clue that 
there was an easier way.
0
Michael
11/13/2003 1:02:45 PM
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote in message news:<BBD82323.15263%eric.vergnaud@wanadoo.fr>...
> Lindsey,
> 
> As a matter of fact, it is feasible to connect a C++ framework to Obj-C
> Cocoa. I've just done it. It's not complete yet, but it's 100% Cocoa, it
> works, with only 6000 lines of Obj-C code, and follows the architecture
> described in Apple's CocoaInCarbon samples (although I'm using CW 8.3 to do
> the job, and a static library for the Obj-C part, which I couldn't manage
> with PB).
> 
> I strongly recommend using Cocoa, since the Cocoa UI framework is much
> closer to Windows GDI than Carbon is, and much safer too IMHO. NSViews are
> pretty much like HWNDs, and they handle all the necessary clipping etc...
> when drawing, much better than HIViews do (their Carbon counterpart). I
> handle all the drawing using Quartz in C, Quartz being the underlying
> graphics engine of Cocoa, which is much more powerful than Quickdraw, and
> more powerful than Win32 GDI. You can use Quartz with Carbon, but it's a
> pain, since a huge part of Carbon was primarily designed for Quickdraw. So
> the only Obj-C code I have is for Cocoa UI objects (windows and controls)
> and threads.
> 
> But above all this, I'd say the event model is much easier to deal with for
> Windows programmer, since it's a preemptive model rather than a polling
> model like Carbon. For example, you don't need a mouse tracking loop in
> Cocoa as you do in Carbon, your custom NSView simply receives a mouseDragged
> message, very similar in concept to the WM_MOUSEMOVE message you get in a
> HWND proc with a SetCapture.
> 
> If you can think of this job as creating a C library that handles the
> C/Cocoa conversion, it's a one man's task, so other programmers won't have
> to learn Obj-C to start with (although I strongly recommend that they do on
> the long term).
> 
> Eric

I read the above and shudder. Not because I don't think it is a bad
idea, but the idea of implementing it in our code is not financially
feasible.

First, we have code that dates back to the time when some program
converted
our programs Pascal code into C code. Second, we're still using all
the oldest calls that are still available from the Toolbox, and third
we've tied our Mac code ineligently (sp?) to our cross-platform core
code. Its all mixed up and some of the mechanisms include heavy
work-arounds to un-mac like design.

We cannot even move to Carbon Events let alone think of converting
every thing to use modern Mac Code. Oh how I would love to do that,
but our application builds an executable that is over 20Mbs in size.
Our source folder informs me that we have 1.47Gbs in there.

What you propose is not feasible for such a large project. We'd be
better off rewriting the whole thing but that would take years and we
wouldn't be making any money. Then we'd go out of business and not
have been able to complete the project anyway.

I appreciate your conviction and suggestions.


Lyndsey
0
lyndsey_ferguson
11/13/2003 2:22:04 PM
In article <mail-61AFE1.17361312112003@localhost>,
 Michael Ash <mail@mikeash.com> wrote:

> In article <droleary.usenet-30CB12.09402312112003@corp.supernews.com>,
>  Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > Cocoa has a Java API as well.  Unfortunately.
> 
> Why is this unfortunate?

It is unfortunate for the developer because the object models aren't 
parity and the Java API has a lot of unclean workarounds to make it fit.  
Other bridges, like Python's, will fit better; scripting languages are 
generally dynamic enough to work well with ObjC.

It is unfortuante for the user because, despite how far it has come, 
Java apps are still slow and bloated compared to the alternatives.  I 
can't point to a single app in widespread use that uses the Java API.  
Users won't tolerate it, and any developer trying to convince a company 
to do Cocoa/Java instead of Cocoa/ObjC should probably be fired.
0
Doc
11/13/2003 4:55:07 PM
In article <macdev-EEBAC5.12272112112003@senator-bedfellow.mit.edu>,
 Miro Jurisic <macdev@meeroh.org> wrote:

> In article <droleary.usenet-30CB12.09402312112003@corp.supernews.com>,
>  Doc O'Leary <droleary.usenet@subsume.com> wrote:
> 
> > Cocoa adoption is slowed down only by stupid developers.  
> 
> But worry not -- sage advice from Doc O'Leary will counteract all that 
> stupidity.

I hope not.  Widespread stupidity is what can make even a dim bulb like 
me seem sage.  If everyone started doing things right, there would be 
less room for me to be successful.  So I'm pretty much going to 
encourage people to stick with crap technologies like Carbon, Java, and 
even switch to Windows.  My technique is currently to look like a 
complete jerk while pointing them to better solutions; they get so 
emotionally miffed they go the other way and then I swoop in with the 
better solution.  The best part is that I can even *tell* them that's 
what I'm doing and they *still* go with the bad tech.  It's hilarious!
0
Doc
11/13/2003 5:04:39 PM
dans l'article edc42e1f.0311130622.8bb7f12@posting.google.com, Lyndsey
Ferguson � lyndsey_ferguson@yahoo.com a �crit le 13/11/03 15:22�:

> I read the above and shudder. Not because I don't think it is a bad
> idea, but the idea of implementing it in our code is not financially
> feasible.
> 
> First, we have code that dates back to the time when some program
> converted
> our programs Pascal code into C code. Second, we're still using all
> the oldest calls that are still available from the Toolbox, and third
> we've tied our Mac code ineligently (sp?) to our cross-platform core
> code. Its all mixed up and some of the mechanisms include heavy
> work-arounds to un-mac like design.
> 
> We cannot even move to Carbon Events let alone think of converting
> every thing to use modern Mac Code. Oh how I would love to do that,
> but our application builds an executable that is over 20Mbs in size.
> Our source folder informs me that we have 1.47Gbs in there.
> 
> What you propose is not feasible for such a large project. We'd be
> better off rewriting the whole thing but that would take years and we
> wouldn't be making any money. Then we'd go out of business and not
> have been able to complete the project anyway.
> 
> I appreciate your conviction and suggestions.
> 
> 
> Lyndsey

Lindsey,

It's nice to hear people speaking of the real world out there, with a
practical standpoint.

If the situation is that bad, maybe you should reconsider the project in
itself. Very frankly, if you can't afford Carbon events, you'll be out of
business anyway, because if you're tied to Classic, your users will run
away.

IMHO, the only 2 credible alternatives are Carbon+CarbonEvents+HIViews and
Cocoa. Any other solution will probably lead to an unacceptable app.

What's the percentage of platform specific UI code in that app ?

Eric

0
Eric
11/13/2003 5:09:48 PM
In article <BBD9796C.1552A%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> If the situation is that bad, maybe you should reconsider the project in
> itself. Very frankly, if you can't afford Carbon events, you'll be out of
> business anyway, because if you're tied to Classic, your users will run
> away.

This doesn't make sense. Carbon still supports all of the old-style 
ugliness like WaitNextEvent(), they're just deprecated and tend to hog 
the CPU. But there's no reliance on Classic implied.
0
Michael
11/13/2003 5:17:19 PM
In article <f7e883a5.0311130329.70d5f274@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Cocoa adoption is being slowed by a LOT of factors. Cococ/ObjC code
> tends to be very verbose, and esoteric in comparison to all the other
> environments that I've seen.

Perhaps you simply haven't "seen" enough.  Don't fault a language when 
you simply don't have a firm language base to approach it on.  How long 
have you done Smalltalk or Lisp development?  Tried any other 
non-bandwagon OO languages like Self or Io?  Really, anyone who is 
confused by the trivial additions that ObjC makes to C shouldn't even 
*think* of touching C++.


> Take string creation/manipulation using
> NSStrings, vs STL strings in C++. Where's the operator overloading???

As Mr. Ash points out, operator overloading as commonly practiced in C++ 
is poorly thought out.  To add is not to append, and so overloading the 
+ operator to make the two look the same is a dumb thing to do.  More to 
the point, ObjC draws a very clear line between where C operations end 
and where object operations begin.

> Even a stupid programmer like myself understands those instantly;
> instead of having to spend time scouring the documentation to find how
> to handle basic data types I could have been just getting on with my
> program. Similarly, the concept of multiple inheritance is far more
> intuitive than protocols.

Michael already responded to this pretty well, so I'll just add that you 
need to be specific when you point to MI as a feature, because it is a 
hack that is used to fill so many roles it isn't funny.  Are you doing 
it for simple code reuse?  Are you doing it for polymorphism?  Are you 
doing it because you have objects poorly defined in the design?  ObjC 
features make MI unnecessary for the thing most people use it for.  
Please detail how your needs are more advanced.

> (Indeed, the only other language I've ever struggled with to the same
> degree - and I've learnt a lot  - is Prolog. And in the programming
> landscape, that's in the "Here Be Dragons" territory.)

Just because you struggle with something doesn't mean it is difficult.  
Sometimes, for whatever reason, people feel a need to make things 
difficult.  I've had situations where ObjC code cleanly does what I had 
previously spent months of coding and tweaking to work moderately well 
in C++.  If I were a fool, I would resent ObjC for making those 6 months 
seem like wasted time; I instead rightly resent C++ for wasting all that 
time.

> Then there's the documentation. Any good, thorough set of
> documentation needs to include three things, a complete reference
> (obviously), sample code (for those "ah, THAT'S what he meant" times),
> and a detailed introduction & discussion. For Cocoa/ObjC, the first
> two are fine, the latter is pretty sparse. 'If you want to bungie
> jump, see NSBungieJump'. Cheers! At least the documentation is
> improving.

So where are your questions when you hit the roadblocks you claim are 
there?  I don't see them posted here.  I have a feeling you never even 
*hit* those blocks.  I have a feeling you're just making excuses to not 
try something new.

> And look at this case: for the first time, I needed to create a button
> with an icon. I looked in the Inspector, and it asked me for a string.
> What string? A resource ID? File name? File path? Absolute or
> relative? What file type?

Is this honestly the kind of thing that you stumble over and can't pick 
yourself up from?  This again points to your apparent unwillingness to 
build a proper base to interact with your development environment.  IB 
is cool not because it holds your hand, but because it allows you to 
create and manipulate interface objects directly.  That is, when in 
doubt, you could check to see that NSButton has -setImage: which takes 
an NSImage, and NSImage has a method +imageNamed: which takes an 
NSString and has a documented lookup procedure.  Just because IB makes 
things simple is no reason to be simple minded about IB.
0
Doc
11/13/2003 5:36:42 PM
dans l'article mail-205474.18171913112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 13/11/03 18:17�:

> In article <BBD9796C.1552A%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> If the situation is that bad, maybe you should reconsider the project in
>> itself. Very frankly, if you can't afford Carbon events, you'll be out of
>> business anyway, because if you're tied to Classic, your users will run
>> away.
> 
> This doesn't make sense. Carbon still supports all of the old-style
> ugliness like WaitNextEvent(), they're just deprecated and tend to hog
> the CPU. But there's no reliance on Classic implied.

Sorry if I the way I wrote it makes it unclear (I agree it does).

Lindsey says "we're still using all the oldest calls that are still
available from the Toolbox ", so it looks like he is tied to Classic, that's
why I mentioned it.

As for Carbon events vs WaitNextEvent, since WaitNextEvent is deprecated,
the chances that it becomes unsupported in the mid-term is not low.

So investing on the short-term might be a complete waste.

Eric

0
Eric
11/13/2003 5:45:32 PM
In article <edc42e1f.0311120617.1f44fd28@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> Yes, I can say that learning an additional language is an obstacle.  I
> consider the attitude of many of our Windows programmers to be quite
> reluctant to do Macintosh programming.

Then, for the sake of your customers, don't let them.  The main reason 
for Windows ports to a Mac failing is because they used idiot Windows 
developers who didn't understand the Mac platform.

> If these programmers are forced to learn an additonal language - they
> are going to do a bad job of the implementation because they are going
> to be throwing it together haphazardly.

This speaks more to their skills as a developer than their ability with 
a language.  Languages are cake, and any developer worth hiring should 
have more than a handful under their belt and fully expect to learn a 
dozen more over time.  If all you can get is someone who's only exposure 
is to Java or C++, their code will probably be crap in other language 
because their code was actually crap in Java and C++ but nobody else 
there had the skills to recognize that fact.

> If our shop is a C++ shop and
> the core of our app is written using C++ as well as the Windows side
> and currently the Macintosh side, it seems to me to be like throwing a
> wrench into the machine if you force Objective-C on the  Macintosh. 

You would be wrong.  Carbon only (barely) makes sense for porting old 
Mac OS 9 apps to Mac OS X.  If you have a Windows app you want to port, 
odds are you're better served by a Cocoa abstraction layer over your 
core business model code.

> We do not have an even team of Mac/Win programmers, we have
> programmers who have percentages of work that they do on both
> platforms.

My bet is that the app comes across as being poorly done on the Mac as a 
result.  If you think otherwise, please feel free to name it so we can 
all see for ourselves.
0
Doc
11/13/2003 5:46:05 PM
In article <edc42e1f.0311130622.8bb7f12@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> First, we have code that dates back to the time when some program
> converted
> our programs Pascal code into C code. Second, we're still using all
> the oldest calls that are still available from the Toolbox, and third
> we've tied our Mac code ineligently (sp?) to our cross-platform core
> code. Its all mixed up and some of the mechanisms include heavy
> work-arounds to un-mac like design.
> 
> We cannot even move to Carbon Events let alone think of converting
> every thing to use modern Mac Code. Oh how I would love to do that,
> but our application builds an executable that is over 20Mbs in size.
> Our source folder informs me that we have 1.47Gbs in there.

This is amusing.  So because you have moutains of (by your own 
admissions) crappy, hacked up, hard to manage Carbon code it somehow 
isn't "financially feasible" to have a properly done Cocoa front end 
instead?  I don't know what percentage of that 1.5GB is Carbon code, but 
I bet you could eliminate 50% of that by using Cocoa instead and get a 
more managable code base at the same time which will end up costing you 
less in the long term than your current environment.

> What you propose is not feasible for such a large project.

It some ways, going from Carbon to Cocoa is *especially* feasible for 
larger projects.  For little hacks, the cost of the jump is much larger 
than what you'd get in return.  For something massive, however, the 
payoffs are huge and some can be realized right away if you smartly plan 
the transition.  You're just unwilling to do that, for whatever reason.
0
Doc
11/13/2003 5:53:58 PM
In article <BBD981CC.1553C%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article mail-205474.18171913112003@localhost, Michael Ash �
> mail@mikeash.com a �crit le 13/11/03 18:17�:
> 
> > In article <BBD9796C.1552A%eric.vergnaud@wanadoo.fr>,
> > Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> > 
> > This doesn't make sense. Carbon still supports all of the old-style
> > ugliness like WaitNextEvent(), they're just deprecated and tend to hog
> > the CPU. But there's no reliance on Classic implied.

> As for Carbon events vs WaitNextEvent, since WaitNextEvent is deprecated,
> the chances that it becomes unsupported in the mid-term is not low.

WaitNextEvent will have to be supported for a very long time because 
many applications still use it.  New code shouldn't use it, though.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/13/2003 6:20:36 PM
In article <edc42e1f.0311130622.8bb7f12@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> We cannot even move to Carbon Events let alone think of converting
> every thing to use modern Mac Code.

BTW, you can move to Carbon events one event and one target at a time.  
It won't affect your existing code.  So as you find things that you can 
do better with them, you can migrate to them.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/13/2003 6:24:09 PM
Michael Ash <mail@mikeash.com> wrote in message news:<mail-178D83.14024513112003@localhost>...

> Of course, we can debate the merits of operator 
> overloading until the sun goes out, but I can't see this being a major 
> stumbling block to adoption; after all, many people come from C or other 
> languages without operator overloading.

Ok, in my case it's been a while since I've used a language that
didn't have operator overloading. Of course it's not a major stumbling
block, but for new adopters, operator (especially assignment operator)
overloading is an intuitive 'learn once, remember always' approach. Do
you know all your initWithXYZ methods off by heart? :)
 
> For strings and similar 'basic' data types, I find the headers to be 
> quick to examine and informative enough when looking for a way to do X, 
> when I don't have a clue what the method would be called. But I'm pretty 
> used to the system by now.

(I think) that was my point, Cocoa/ObjC is powerful, but it takes
getting used to it's ways. For instance, I was thrilled when I
unearthed the NSArchiver/Unarchiver classes, but then found I had to
delve NSDecimalNumber, then into NSNumber documentation to figure out
how to archive non-object (in my case, numeric) data; where I had
until then simply used integer types.

> MI and protocols aren't the same thing at all. If you're referring to 
> using MI to allow separate objects with no common parent to respond to 
> the same messaging interface, ObjC handles that in a completely 
> different manner (as I'm sure you know) in which protocols are only a 
> very peripheral and unnecessary thing.

It's possible I'm confused (you'd never have guessed..)

PowerPlant has 'mix in' classes that, when added as a
parent/superclass, provide extra functionality. Sometimes that's all
that's required, at other times you must override certain methods.
Protocols in ObjC seemed to me like the closest equivalent.

> > (Indeed, the only other language I've ever struggled with to the same
> > degree - and I've learnt a lot  - is Prolog. And in the programming
> > landscape, that's in the "Here Be Dragons" territory.)
> 
> I found ObjC to be quite easy to learn, as have many others. I don't 
> mean this as any slight against you, just a point of data. It seems to 
> me that a great many people find it very easy, and some people find it 
> very difficult for reasons that the rest of us don't understand. :) 

Different strokes for different folks I guess, I'm perfectly happy
muddling about in assembly language.

> Of course, I also thought Prolog was fairly easy too, so I'm probably 
> not a normal case. :)

Ok, I take it back. You're just a freak!

> > Then there's the development tools. The Xcode & IB integration is
> > sorely lacking in comparison to the other options.
> 
> Are you referring to other options on the Mac, and if so, what are they?

Well, primarily I was referring to PC tools - such as Delphi and
PowerBuilder. While they're lacking in other areas, their sheer
simplicity and integration allow very quick pick up and build times. I
started PC development,learnt both
tools/languages and developed commercial apps using both quicker than
I've picked up ObjC/Cocoa (sadly for me!)

> This can be done less painfully by taking advantage of drag-and-drop; 
> once you've changed a header in Xcode, just drag the file from your 
> project window or the file's window title bar into your nib's main 
> window in IB, and everything gets read. 

The reverse is a bit more problematic for me, as it involves merging
header files.

> But once you've done that, you can just go to the Images tab of your 
> main nib window and drag the appropriate image onto your button. Drag 
> and drop to the rescue again.

D'oh! Thanks, I didn't know that. (The one problem with drag 'n' drop,
is if it isn't ubiquitous, it's not obvious when it's available).
Thanks for your comments, btw, much appreciated.

Mike.
0
google
11/13/2003 6:49:21 PM
In article <ejalbert-E1A3C3.10240913112003@news.stanford.edu>,
 Eric Albert <ejalbert@stanford.edu> wrote:
> BTW, you can move to Carbon events one event and one target at a time.  
> It won't affect your existing code.  So as you find things that you can 
> do better with them, you can migrate to them.

And probably the first thing one should do is move nullEvt processing 
into an event loop timer and start passing much larger values to WNE().  
This gives you much more control over idling/tracking behavior and 
drastically reduces your application's CPU usage when it isn't busy.

Most people's complaints about WNE() stem from applications that pass 0 
or 1 for the sleep time, which results in your application not ever 
properly going to sleep on OS X.
0
Tom
11/13/2003 7:08:39 PM
In article <f7e883a5.0311131049.1a840173@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Ok, in my case it's been a while since I've used a language that
> didn't have operator overloading. Of course it's not a major stumbling
> block, but for new adopters, operator (especially assignment operator)
> overloading is an intuitive 'learn once, remember always' approach.

In the case of strings, at least, it gives you almost nothing. You have 
an easy way to concatenate strings, an easy way to get the character at 
a particular index, and some other fairly simple stuff like equality 
testing. All the other operations take place with regular member 
functions. My experience with STL isn't very great, but those other 
operations seem more obscure and hard to figure out than the equivalent 
in Cocoa.

> Do
> you know all your initWithXYZ methods off by heart? :)

I know all the ones I need commonly. For the rest, I make a best-guess 
as to what the method name starts with, then either command-double-click 
it or hit the code completion key (if I'm in Xcode) and I get a nice 
list of matching methods. Once I figured out all of the basic shortcuts 
for accessing documentation (cmd-shift-D, type class name, enter; 
googling for "class_name site:apple.com", command/option-double-click in 
PB, etc.) I didn't have trouble finding all of the easy one-method stuff.

> (I think) that was my point, Cocoa/ObjC is powerful, but it takes
> getting used to it's ways. For instance, I was thrilled when I
> unearthed the NSArchiver/Unarchiver classes, but then found I had to
> delve NSDecimalNumber, then into NSNumber documentation to figure out
> how to archive non-object (in my case, numeric) data; where I had
> until then simply used integer types.

I'm afraid I have no idea what you're talking about here. Why don't 
encodeInt: and friends work?

> It's possible I'm confused (you'd never have guessed..)
> 
> PowerPlant has 'mix in' classes that, when added as a
> parent/superclass, provide extra functionality. Sometimes that's all
> that's required, at other times you must override certain methods.
> Protocols in ObjC seemed to me like the closest equivalent.

Protocols in ObjC accomplish a few functions, pretty much none of which 
match up with your description of this use of MI. The most important 
function of protocls is simply documentation (ex. NSCopying, NSCoding), 
where it's a convenient description of which methods you have to 
implement and what they need to do. Less commonly, protocols can be used 
to efficiently check if an object responds to a set of messages in an 
efficient manner, by sending one respondsToProtocol: message instead of 
sending a bunch of respondsToSelector: messages.

The dynamic nature of ObjC means that protocols are not necessary to 
allow two classes to respond to the same message without sharing a 
common parent. For example, if your class responds to -initWithCoder: 
and -encodeWithCoder:, your class can be archived, even if you don't 
declare that you conform to NSCoding.

Protocols can't carry code with them, they're just method declarations, 
so you never get any implementation 'for free' by conforming to a 
protocol, unlike what may happen with MI in C++. 

There is an interesting framework which implements 'concrete protocols'; 
protocols that can have default implementations for their methods. This 
is done with some macros and runtime hackery. I've never used it, so I 
have no idea how it is. It's at 
<http://www.toastedmarshmallow.com/Frameworks/ConcreteProtocol/>.

I haven't seen anything like 'mix in' classes in Cocoa. I don't know if 
it's because it's just a different design philosophy or because the 
language makes it more difficult. You can fake MI in ObjC by 
implementing -forwardInvocation:, but it can be some work to do. I think 
this is a case where there isn't really an equivalent in either 
direction.

[snip trouble learning ObjC]

[IB, Xcode, other tools]
> Well, primarily I was referring to PC tools - such as Delphi and
> PowerBuilder. While they're lacking in other areas, their sheer
> simplicity and integration allow very quick pick up and build times. I
> started PC development,learnt both
> tools/languages and developed commercial apps using both quicker than
> I've picked up ObjC/Cocoa (sadly for me!)

I don't really have any experience with those tools (I think I used 
Delphi for a little while, long ago enough that I don't really recall) 
so I'll have to take your word for it.

As far as my experience goes, I took a job involving ObjC programming 
with no knowledge of the language (not using Cocoa, though, using 
another unrelated framework) and ended up having to pick it up very 
fast, which I did.

> > This can be done less painfully by taking advantage of drag-and-drop; 
> > once you've changed a header in Xcode, just drag the file from your 
> > project window or the file's window title bar into your nib's main 
> > window in IB, and everything gets read. 
> 
> The reverse is a bit more problematic for me, as it involves merging
> header files.

I never modify anything other than the fake FirstResponder class in IB. 
I always make my changes in PB/Xcode and move my changes to IB from 
there, so I never run into this problem. Mostly because I realized very 
quickly that the integration was not the best in this case, so I gave up 
on it right away. I'm more comfortable creating my outlets and actions 
'for real' in my code anyway.

> D'oh! Thanks, I didn't know that. (The one problem with drag 'n' drop,
> is if it isn't ubiquitous, it's not obvious when it's available).

As with many things in Cocoa, your best indication that you're doing 
something wrong is that it's taking you more than ten minutes. If I had 
applied that rule to IB, I probably would have figured this out sooner.

> Thanks for your comments, btw, much appreciated.

Likewise. It's always nice to hear from the other side. And of course, 
if I can make another convert, that's great too. :)
0
Michael
11/13/2003 8:57:21 PM
In article <BBD981CC.1553C%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Lindsey says "we're still using all the oldest calls that are still
> available from the Toolbox ", so it looks like he is tied to Classic, that's
> why I mentioned it.

Well, one of Carbon's design goals is to facilitate porting from 
Classic, so depending on how the code works, it may be possible to come 
up with a decent (although not perfect, lots of ported-from-Classic apps 
are obviously different) conversion without too much pain. But neither 
of us really knows.

> As for Carbon events vs WaitNextEvent, since WaitNextEvent is deprecated,
> the chances that it becomes unsupported in the mid-term is not low.
> 
> So investing on the short-term might be a complete waste.

I don't see why Apple would simply yank WNE. Its mere presence doesn't 
disturb anybody, and it's not as if it's a great deal of effort to keep 
it in Carbon. Hell, even GetNextEvent() is still in Carbon. And anyway, 
as another poster said, it's possible to incrementally move code away 
from WNE towards the modern Carbon Event model. In which case they could 
make an initial version that works, and uses WNE, then slowly migrate 
afterwards.

Of course, I think they should do it with Cocoa too. :)
0
Michael
11/13/2003 9:06:30 PM
 Michael Ash <mail@mikeash.com> wrote:

> Are you aware of Apple's Objective-C++ compiler, which allows you to mix 
> Objective-C and C++ code? This is used, for example, in Apple's WebCore, 
> which wraps KHTML in ObjC code to make it available for Cocoa programs.

So Cocoa exception macros mix with C++ exceptions by now? 
 
> [Cocoa] Of course you may not start producing very good code right away. 

So who is writing good - and SOLID - Cocoa code? Quite a bunch of the 
Cocoa Applications I see crashing due undefined behavior with some 
unhandled Objc message or unhandled nil objects, something current C++ 
coding practice (exceptions, smart objects, strong type checking) should 
avoid. The Cocoa code I have seen is only lean when error checking is 
practically missing.

Regards,
      Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
11/13/2003 10:32:54 PM
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote in message news:<BBD9796C.1552A%eric.vergnaud@wanadoo.fr>...
> dans l'article edc42e1f.0311130622.8bb7f12@posting.google.com, Lyndsey
> Ferguson � lyndsey_ferguson@yahoo.com a �crit le 13/11/03 15:22 :
> 

> Lindsey,
> 
> It's nice to hear people speaking of the real world out there, with a
> practical standpoint.
> 
> If the situation is that bad, maybe you should reconsider the project in
> itself. Very frankly, if you can't afford Carbon events, you'll be out of
> business anyway, because if you're tied to Classic, your users will run
> away.
> 
> IMHO, the only 2 credible alternatives are Carbon+CarbonEvents+HIViews and
> Cocoa. Any other solution will probably lead to an unacceptable app.
> 
> What's the percentage of platform specific UI code in that app ?
> 
> Eric

Mr. Vergnaud,

First, it's Lyndsey :)

The project is "the" staple product. It cannot be reconsidered :)

I think Carbon Events are fantastic. They give me a lot more power and
I am putting them in as needed where I can.

We're using PowerPlant for our Mac OS side, if it was a straight
recompile of PowerPlant X to start using HIViews and Carbon Events, we
would most likely switch yesterday.

I couldn't tell you what percentage of platform specific UI we have
because it's not like we have a true cross-platform library where a
non-platform programmer calls:

CreateAppWindow( position, size, type ) that works appropriately on
both Mac and Windows. We do have a little bit of that using older
style calls with a Mac API emulation layer on top of the Windows
implementation. We also have the platform implementations done in MFC
on Windows and PowerPlant on the Mac. I would say a large percentage
of the code is platform specific.

And to the others who posted:

"we're still using the oldest calls that are still available from the
toolbox",

Our App is Carbon and runs in both OS X and OS 9 using mostly the same
code. It also runs in Windows :)

And to Mr. O'Leary, I would like to address some points you brought
up:

- First, I wouldn't characterize our code as crappy and hacked up. I
am not in such a positon to say so as I've worked mostly in the
fringes, fixing what I could in the depths or creating new systems
using new technology where possible.

- I'm not sure I was clear in why it is not financially feasible: We
cannot take the time necessary to re-write our software to make it as
modern as necessary. If you stop and think about it, understand that
it would take a great deal of time - not a couple of months.  During
that time we are bleeding money - sinking.  We can do this in a step
by step fashion, and that is best served in my mind by using Carbon as
there isn't any new way to learn, just the new APIs.

- I have no control over how the Windows programmers do their Mac
portions. I've tried to educate and fix, but I have my own
responsibilites that require a great deal of time. I'm just a peon.

- Our developers know a tonne of languages.  But the current
philosophy here is to try and make the App using a cross-platform
language. I agree.  If we were writing an Application from scratch and
it was only Mac, then maybe Cocoa would be considered.

- I'm glad you agree that Carbon makes sense for porting Mac OS 9 apps
to X. Our Application has been around on the Mac since circa 1987.
This is not a port from Windows, on the contrary, our Windows version
is a port from the original Mac version.

Mr. Dowdy:

I agree with you completely and we do need to install the Carbon Event
Timer mechanism to implement our idle time processing. I'm sure we
would see a responsiveness improvement.  There are many things that we
would love to do right now, but the resources are being used on other
more high-priority tasks. I'm sure that any professional Software
Engineer can emphathise with being unable to address everything that
they would like to.

--

Well, I've tried to address why I feel that we are not switching to
Cocoa. I may be wrong and next year we may be told to learn Cocoa. But
I wouldn't bet on it.  I don't appreciate how some people get upset
when Cocoa/Carbon are discussed. Can we not all just develop and let
be?

Cheers,
Lyndsey
0
lyndsey_ferguson
11/13/2003 10:44:17 PM
In article <BBD6DCA8.151AC%eric.vergnaud@wanadoo.fr>,
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

>Is this because Cocoa requires Objective-C ? If it is, it's interesting to
>see that I'm not the only one in this group to think that Objective-C slows
>down Cocoa adoption, especially in a multiplatform context.

Objective-C has slowed down Cocoa adoption -- no doubt about it.
But for the people who have adopted it it speeds up programming
and debugging by such a huge margin that it's taking over anyway.


0
slavins
11/13/2003 11:55:18 PM
In article <edc42e1f.0311131444.111d06b4@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> Well, I've tried to address why I feel that we are not switching to
> Cocoa. I may be wrong and next year we may be told to learn Cocoa. But
> I wouldn't bet on it.  I don't appreciate how some people get upset
> when Cocoa/Carbon are discussed. Can we not all just develop and let
> be?

Well, that's just the way people are. Trying to make programmers not 
argue about stuff like that is like trying to make them not breathe.
0
Michael
11/14/2003 8:57:28 AM
In article <bp10qm$1jhcui$1@ID-2640.news.uni-berlin.de>,
 Thomas Engelmeier <aug03_nospam@engelmeier.com> wrote:

>  Michael Ash <mail@mikeash.com> wrote:
> 
> > Are you aware of Apple's Objective-C++ compiler, which allows you to mix 
> > Objective-C and C++ code? This is used, for example, in Apple's WebCore, 
> > which wraps KHTML in ObjC code to make it available for Cocoa programs.
> 
> So Cocoa exception macros mix with C++ exceptions by now? 

I doubt it. The new part-of-the-language exception constructs (@try, 
@throw, etc.) are supposed to be binary-compatible with the old 
exception macros, so I'm sure they have the same limitations.

I don't see why you would take my statement as to imply ObjC/C++ 
exception compatibility, though. C's setjmp()/longjmp() aren't very 
compatible with C++ objects either, but people still manage. Of course 
you have to be careful with exceptions; if a C++ exception can be thrown 
through Cocoa code, then you have to make sure everything is properly 
autoreleased. If an ObjC exception can be thrown through C++ code, then 
you have to make sure nothing bad will happen as a result of stack-based 
objects' destructors not being called.

I didn't say it was some perfect nirvana. What it *is*, is a way to mix 
ObjC and C++. I personally find Safari to be an excellent product, so 
obviously it is possible to produce something that works very well using 
ObjC++.

> > [Cocoa] Of course you may not start producing very good code right away. 
> 
> So who is writing good - and SOLID - Cocoa code? Quite a bunch of the 
> Cocoa Applications I see crashing due undefined behavior with some 
> unhandled Objc message or unhandled nil objects, something current C++ 
> coding practice (exceptions, smart objects, strong type checking) should 
> avoid.

With the exception of the Finder and this newsreader, every application 
I use on anything resembling a regular basis is a Cocoa app, both Apple 
and third-party stuff. So my impression is that a lot of people are 
writing good and solid Cocoa code. Of course bad or inexperienced 
programmers will write Cocoa code that throws a lot of exceptions (note 
that unhandled messages always generate exceptions, not crashes, and nil 
objects either generate exceptions or are simply a no-op in the case of 
messaging to nil), just like bad or inexperienced programmers will write 
C++ code that segfaults a lot.

> The Cocoa code I have seen is only lean when error checking is 
> practically missing.

Error checking is only really necessary when interacting with something 
that can produce an error in the normal course of operation. By this, I 
mean things like reading from a file, opening a socket, etc. Sending a 
message to an object of unknown type doesn't need error-checking; either 
you catch the exception that it will throw, or you test your code to be 
sure that the wrong type of object is never passed in. The facts that a 
lot of errors are signalled by returning nil, and messages to nil have 
no effect, can be used to cleanly delay error checking until the end of 
a sequence of messages.

One 'problem' is that Cocoa makes it very easy for someone who is 
inexperienced to write an app that looks good, but functions badly. 
Whereas a beginning C++ programmer may be struggling to put a window on 
the screen, a beginning Cocoa programmer has a nice-looking GUI wrapped 
around code that is probably doing all kinds of weird, horrible stuff. 
As a result, a fair number of these bad-on-the-inside programs actually 
get released to the world. You shouldn't take them as being 
representative any more than the equivalent 
ugly-and-segfaulting-all-the-time C++ program.
0
Michael
11/14/2003 11:45:43 AM
dans l'article mail-9171E3.12454314112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 14/11/03 12:45�:

> I didn't say it was some perfect nirvana. What it *is*, is a way to mix
> ObjC and C++. I personally find Safari to be an excellent product, so
> obviously it is possible to produce something that works very well using
> ObjC++.

By the way, CW allows this since 8.3. I'm using it every day.

Eric

0
Eric
11/14/2003 12:01:03 PM
Michael Ash <mail@mikeash.com> wrote in message news:<mail-1C8989.21572113112003@localhost>...
> In the case of strings, at least, it gives you almost nothing. You have 
> an easy way to concatenate strings, an easy way to get the character at 
> a particular index, and some other fairly simple stuff like equality 
> testing. 

I'm not for a moment suggesting these things can't be done in ObjC or
Cocoa. Merely that by reusing a simple, common metaphor (such as
operator + for string concatenation), a programmer new to ObjC/Cocoa
trys it, remembers and moves on. IMO, the less reliance on
framework-specific methods of simple manipulating of basic data types
(in this case, strings) the better.

Ease of use isn't just something for newbie users, even for seasoned
programmers it's useful to reuse common concepts so they don't have to
learn from scratch. (FYI, I knew a developer who used to force his
(newbie) users to use old green screen Wang terminals for word
processing and the like, because he didn't/couldn't learn how to
program for Windows or Macs).

> I'm afraid I have no idea what you're talking about here. Why don't 
> encodeInt: and friends work?

Isn't that method only in NSKeyedArchiver? I was using non-keyed
archiving. In any case, I found another way around the problem.

[snip for brevity]
> I haven't seen anything like 'mix in' classes in Cocoa. I don't know if 
> it's because it's just a different design philosophy or because the 
> language makes it more difficult. You can fake MI in ObjC by 
> implementing -forwardInvocation:, but it can be some work to do. I think 
> this is a case where there isn't really an equivalent in either 
> direction.

Thanks for the info, seems I was wrong to draw a parallel between the
two. The concept of mix-in classes is the most useful aspect of
multiple inheritance to me, and seems to me to be a very OO, (i.e.
code reuse with minimal work involved).

> As far as my experience goes, I took a job involving ObjC programming 
> with no knowledge of the language (not using Cocoa, though, using 
> another unrelated framework) and ended up having to pick it up very 
> fast, which I did.

Which is probably the best way to learn! I'll put my hand up here and
say I've never had a OSX only contract, so I've never 'had' to use
ObjC. I am using it now for my pet project, though without the
pressure of someone looking over my shoulder! ;)

> I always make my changes in PB/Xcode and move my changes to IB from 
> there, so I never run into this problem. Mostly because I realized very 
> quickly that the integration was not the best in this case, so I gave up 
> on it right away. I'm more comfortable creating my outlets and actions 
> 'for real' in my code anyway.

Yup, that's what I now do too. 

But this is the benefit of more integrated toolset, there's no need to
manually create the actions and controls, nor connect them.

> As with many things in Cocoa, your best indication that you're doing 
> something wrong is that it's taking you more than ten minutes. If I had 
> applied that rule to IB, I probably would have figured this out sooner.
>
:)
 
> > Thanks for your comments, btw, much appreciated.
> 
> Likewise. It's always nice to hear from the other side. And of course, 
> if I can make another convert, that's great too. :)

How many do you have to convert before you get the free T-shirt? No,
I'm already convinced, I just feel a little frustrated it's taken
(taking?) longer than I expected to get up to speed. I'd like to think
it has more to do with the reasons I've mentioned, rather than being a
stoopid programmer!

Cheers!
Mike.
0
google
11/14/2003 3:58:36 PM
Doc O'Leary <droleary.usenet@subsume.com> wrote in message news:<droleary.usenet-E1287C.11364213112003@corp.supernews.com>...
> In article <f7e883a5.0311130329.70d5f274@posting.google.com>,
>  google@whooley.utvinternet.com (Mike Whooley) wrote:
> 
> > Cocoa adoption is being slowed by a LOT of factors. Cococ/ObjC code
> > tends to be very verbose, and esoteric in comparison to all the other
> > environments that I've seen.
> 
> Perhaps you simply haven't "seen" enough.  Don't fault a language when 
> you simply don't have a firm language base to approach it on.  How long 
> have you done Smalltalk or Lisp development?  Tried any other 
> non-bandwagon OO languages like Self or Io?  Really, anyone who is 
> confused by the trivial additions that ObjC makes to C shouldn't even 
> *think* of touching C++.

No, I haven't used Smalltalk or Lisp. (I'd never even heard of Self or
Io, are these in common usage?) I've developed with C, C++, (now ObjC
too), Pascal (incl Delphi Pascal), Object Pascal, Fortran, in addition
to high level stuff like PowerScript; and assembly on various
platforms. That's a reasonable language base consisting of high level,
low level, OO and non-OO languages to compare to. (I'm not sure what
you mean by 'bandwagon'. )

> > Take string creation/manipulation using
> > NSStrings, vs STL strings in C++. Where's the operator overloading???
> 
> As Mr. Ash points out, operator overloading as commonly practiced in C++ 
> is poorly thought out.  To add is not to append, and so overloading the 
> + operator to make the two look the same is a dumb thing to do.

On a logical level, you're right of course. '+' doesn't do any kind of
bizzard character munging. On a pragmatic level, you're dead wrong.
Even newbie OO programmers are comfortable with the concept of such
operators, it's a good idea to leverage that familiarity.

>  More to 
> the point, ObjC draws a very clear line between where C operations end 
> and where object operations begin.

I don't see why that's a good thing.

> Michael already responded to this pretty well, so I'll just add that you 
> need to be specific when you point to MI as a feature, because it is a 
> hack that is used to fill so many roles it isn't funny.  Are you doing 
> it for simple code reuse?  Are you doing it for polymorphism?  Are you 
> doing it because you have objects poorly defined in the design?  ObjC 
> features make MI unnecessary for the thing most people use it for.  
> Please detail how your needs are more advanced.

I really don't follow your logic here. MI is wrong because it's useful
and flexible?

> Just because you struggle with something doesn't mean it is difficult.  
> Sometimes, for whatever reason, people feel a need to make things 
> difficult.  I've had situations where ObjC code cleanly does what I had 
> previously spent months of coding and tweaking to work moderately well 
> in C++.  If I were a fool, I would resent ObjC for making those 6 months 
> seem like wasted time; I instead rightly resent C++ for wasting all that 
> time.

Snap. 

Just because other developers find some aspects of ObjC
counter-intuitive doesn't make them stupid either. Personally, I
picked up, and have been using C++ for some time without problems. The
only drawback I've experienced is the lack of decent RAD tools on the
Mac.

> So where are your questions when you hit the roadblocks you claim are 
> there?  I don't see them posted here.  I have a feeling you never even 
> *hit* those blocks.  I have a feeling you're just making excuses to not 
> try something new.

No, posting to a newsgroup for help is never my first recourse, I find
it better to try and work through the problem first. (But thanks for
the amateur psychology).

> Is this honestly the kind of thing that you stumble over and can't pick 
> yourself up from?  

No, it's just one example of an anachronism in a Cocoa development
tool, which forced me to waste my precious time trying to figure out
how to perform the simplest of actions. Had it been a button and Open
panel, it would have taken 10 seconds. Instead, it took me several
minutes looking through sample projects. When is inconvenience ever a
good thing?

> This again points to your apparent unwillingness to 
> build a proper base to interact with your development environment.  

This again points to your apparent willingness to resort to amateur
psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
toolset.
 
>IB 
> is cool not because it holds your hand, but because it allows you to 
> create and manipulate interface objects directly.  That is, when in 
> doubt, you could check to see that NSButton has -setImage: which takes 
> an NSImage, and NSImage has a method +imageNamed: which takes an 
> NSString and has a documented lookup procedure.  Just because IB makes 
> things simple is no reason to be simple minded about IB.

I didn't, because the image icon wasn't something I wanted to hard
code.
(And less of the insults, eh?)

Mike.
0
google
11/14/2003 4:33:16 PM
In article <edc42e1f.0311131444.111d06b4@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> The project is "the" staple product. It cannot be reconsidered :)

If your users can "reconsider" it (i.e., switch to an alternative), then 
your business *must* reconsider it.

> - I'm not sure I was clear in why it is not financially feasible: We
> cannot take the time necessary to re-write our software to make it as
> modern as necessary. If you stop and think about it, understand that
> it would take a great deal of time - not a couple of months.  During
> that time we are bleeding money - sinking.  We can do this in a step
> by step fashion, and that is best served in my mind by using Carbon as
> there isn't any new way to learn, just the new APIs.

I understand why you think that, but you're wrong.  Cocoa is not as 
difficult as you imagine it to be, and there is absolutely no reason you 
couldn't do an R&D type fork of your code to investigate how quickly and 
how far a Cocoa solution would get in a month and extrapolate to 
completion.  Of course I'd recommend using someone who actually knows 
how to use Cocoa, because your getting up to speed would hinder progress 
initially but you could easily pick it up if the experiment proves a 
success.

> - Our developers know a tonne of languages.  But the current
> philosophy here is to try and make the App using a cross-platform
> language. I agree.  If we were writing an Application from scratch and
> it was only Mac, then maybe Cocoa would be considered.

But this isn't a language issue, it is a *design* issue.  For example, 
do you even have your business code/objects in their own library?  If 
you do, it should be cross-platform without an eye blink and everything 
else GUI-wise is independent of that and the only reason to have a 
Carbon interface instead of a Cocoa one is legacy code, which you say 
isn't so hot to deal with.

> - I'm glad you agree that Carbon makes sense for porting Mac OS 9 apps
> to X. Our Application has been around on the Mac since circa 1987.
> This is not a port from Windows, on the contrary, our Windows version
> is a port from the original Mac version.

Then honestly, on modern systems, it probably suffers from a lot of 
unnecessary cruft, both under Mac OS X and Windows.  It may look cheaper 
to maintain what you have, but odds are it's not in the long term.  Even 
if you insist on sticking with Carbon, it sounds like there are a lot of 
changes that should be made to clean things up, but someone there (maybe 
you) thinks it's more expense to do things right than it really is.

> Well, I've tried to address why I feel that we are not switching to
> Cocoa. I may be wrong and next year we may be told to learn Cocoa. But
> I wouldn't bet on it.  I don't appreciate how some people get upset
> when Cocoa/Carbon are discussed. Can we not all just develop and let
> be?

No.  :-)  The way I see it, it's about the users.  Far too many Carbon 
"ports" fail to leave their OS 9 roots behind, and they make for suck 
applications on OS X.  I'm here using MT-NewsWatcher and I don't 
understand why the message list doesn't use a standard outline view.  
The developer was *lazy* to simply recycle their old code and it leaves 
me as a user with an app that just doesn't fit interface-wise on my 
system.  Cocoa makes the cleanest break from the cruft and does it in a 
way that encourages reuse; the developer has *less* code to maintain if 
they use the standard outline view.

Odds are your project suffers many of the same problems and would 
realize many of the same benefits.  The shame is that it doesn't sound 
like you're in a position to actually benefit the company.  It'd be much 
better if you were telling others what should be used instead of waiting 
to be told what to do.
0
Doc
11/14/2003 4:57:16 PM
In article <f7e883a5.0311140758.5cf70698@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Michael Ash <mail@mikeash.com> wrote in message 
> news:<mail-1C8989.21572113112003@localhost>...
> > In the case of strings, at least, it gives you almost nothing. You have 
> > an easy way to concatenate strings, an easy way to get the character at 
> > a particular index, and some other fairly simple stuff like equality 
> > testing. 
> 
> I'm not for a moment suggesting these things can't be done in ObjC or
> Cocoa. Merely that by reusing a simple, common metaphor (such as
> operator + for string concatenation), a programmer new to ObjC/Cocoa
> trys it, remembers and moves on. IMO, the less reliance on
> framework-specific methods of simple manipulating of basic data types
> (in this case, strings) the better.
> 

In theory, this is reasonable, but in practice, the  basic data types - 
in specific strings, fail for OS X development because they don't 
cleanly support Unicode (which is important for OS X programs).  So you 
are then left with either CFStrings (via Carbon and "plain" C/C++) or 
NSString (via Cocoa and Objective-C).

I've used both, and NSStrings are far easier to use, if for no other 
reason than auto-release pools, but also because CFString API seems 
"have as many parameters as possible in a routine to handle every 
possible case even though 99% of the times you don't need them" (how 
many people have actually used a CFAllocator other than the default one?)
0
Glenn
11/14/2003 5:00:50 PM
dans l'article f7e883a5.0311140833.5709d0b7@posting.google.com, Mike Whooley
� google@whooley.utvinternet.com a �crit le 14/11/03 17:33�:

> This again points to your apparent willingness to resort to amateur
> psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
> toolset.

So it seems I'm not the only one to think that some people on this list
simply won't accept facts.

Eric

0
Eric
11/14/2003 5:43:45 PM
In article <BBDAD2E1.15762%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article f7e883a5.0311140833.5709d0b7@posting.google.com, Mike Whooley
> � google@whooley.utvinternet.com a �crit le 14/11/03 17:33�:
> 
> > This again points to your apparent willingness to resort to amateur
> > psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
> > toolset.
> 
> So it seems I'm not the only one to think that some people on this list
> simply won't accept facts.

Perhaps, but you seem to be the only one who thinks *everyone* simply 
won't accept facts. :P
0
Michael
11/14/2003 8:25:44 PM
In article <f7e883a5.0311140758.5cf70698@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> I'm not for a moment suggesting these things can't be done in ObjC or
> Cocoa. Merely that by reusing a simple, common metaphor (such as
> operator + for string concatenation), a programmer new to ObjC/Cocoa
> trys it, remembers and moves on. IMO, the less reliance on
> framework-specific methods of simple manipulating of basic data types
> (in this case, strings) the better.

Well, in C, ObjC, and even C++, strings aren't really basic data types. 
In ObjC, everything that isn't a primitive has different semantics, 
whereas in C++, non-primitives can use the same semantics as primitives. 
This can be good or bad; the problem is when it breaks down. 
Concatenating constant strings is one example of where the 
objects-act-like-primitives thing breaks down in C++, and there are 
others. That's what Doc meant (I think) when he says ObjC draws a clear 
line between C and ObjC. ObjC objects aren't primitives and operations 
on them have very different semantics and runtime costs; the operations 
reflect that.

You could probably use Objective-C++ to write some automatic coercions 
that would transform id to a C++ string and back when you needed it. I 
would be very hesistant at how well such an approach would handle 
non-english languages, though. :)

> Ease of use isn't just something for newbie users, even for seasoned
> programmers it's useful to reuse common concepts so they don't have to
> learn from scratch.

I agree completely, but I don't see this as an ease-of-use thing, just a 
less-typing thing. For strings, the number of operations you get 'for 
free' with operator overloading is so small as to be insignificant. 
(Really just concatenation and comparison; stuff like assignment 
overloading doesn't apply for a language that doesn't have 
stack-allocated objects anyway.)

Now, I'm not totally against operator overloading by any means. For 
mathematical data types, I think they're great. It's very nice to be 
able to make a vector data type or a complex number type, or some other 
sort of numerical type where you can just write out your operations in 
normal mathematical notation in the program. But for non-numerical 
types, at least in C++, I think operator overloading does more harm than 
good. Strings aren't mathematical types, so the convenience gained by 
being able to 'add' them is very small. And I won't even get started on 
the amount of silliness that arises from overloading << and >> for IO 
operations.

> > I'm afraid I have no idea what you're talking about here. Why don't 
> > encodeInt: and friends work?
> 
> Isn't that method only in NSKeyedArchiver? I was using non-keyed
> archiving. In any case, I found another way around the problem.

Sorry, I made a mistake about the method name. You're right that 
encodeInt: and friends is only in NSKeyedArchiver. Strangely, NSArchiver 
has a different method for every kind of primitive object, 
encodeValueOfObjCType:at:. You use it like this: [coder 
encodeValueOfObjCType:@encode(float) at:&myFloat]. It works for any 
primitive type. I have to chalk this up to 'failure to properly read the 
documentation.' :)

> Thanks for the info, seems I was wrong to draw a parallel between the
> two. The concept of mix-in classes is the most useful aspect of
> multiple inheritance to me, and seems to me to be a very OO, (i.e.
> code reuse with minimal work involved).

I have no experience with this, so could you give me an example or two 
of how this actually ends up working in practice? I think I get the 
idea, but I'd like to know how it works for real.

> > As far as my experience goes, I took a job involving ObjC programming 
> > with no knowledge of the language (not using Cocoa, though, using 
> > another unrelated framework) and ended up having to pick it up very 
> > fast, which I did.
> 
> Which is probably the best way to learn! I'll put my hand up here and
> say I've never had a OSX only contract, so I've never 'had' to use
> ObjC. I am using it now for my pet project, though without the
> pressure of someone looking over my shoulder! ;)

I haven't had an OS X only contract either. When you see me talking 
about how ObjC is cross-platform, I'm not just blathering; I worked on 
an ObjC project running on Linux and Windows for about a year and a 
half. I only started with Cocoa later on. And let me tell you, compared 
to Swarm (the ObjC framework I was using on that project), Cocoa is a 
paradise of understandability, good design, and excellent documentation.

> But this is the benefit of more integrated toolset, there's no need to
> manually create the actions and controls, nor connect them.

You basically pull up the "onClick" action in the interface creator 
thingy and type your code in, right? That would be nice, but Apple is so 
tied to ObjC and gcc, which in turn are very heavily tied to the old C 
way of files-and-modules-and-makefiles development that I doubt this 
will happen.

> How many do you have to convert before you get the free T-shirt?

I don't know. I trust that I will be contacted once I have enough. Or 
perhaps it will simply arrive in the mail one fine morning....

> No,
> I'm already convinced, I just feel a little frustrated it's taken
> (taking?) longer than I expected to get up to speed. I'd like to think
> it has more to do with the reasons I've mentioned, rather than being a
> stoopid programmer!

Well, as I said, some people just don't seem to get it quickly, while 
many of us do. Unlike others, I don't think it's because they're stupid. 
But I am at a total loss to explain why.

[and now some replies to stuff from your message to Doc...]
> No, I haven't used Smalltalk or Lisp. (I'd never even heard of Self or
> Io, are these in common usage?) I've developed with C, C++, (now ObjC
> too), Pascal (incl Delphi Pascal), Object Pascal, Fortran, in addition
> to high level stuff like PowerScript; and assembly on various
> platforms. That's a reasonable language base consisting of high level,
> low level, OO and non-OO languages to compare to.

The thing is, many people consider C++ to be an OO language, and it can 
even be true depending on what you call OO, but it's not the same kind 
of OO as SmallTalk, Self, or Objective-C. So unless Object Pascal or 
your 'high level stuff' had a very non-C++ OO system, then I would say 
your language base does not consist of OO languages to compare to. A lot 
of people who do a lot of C++ tend to think that C++ OO is simply OO, 
when in fact there are several different approaches to OO that produce 
very different capabilities and results. Some people, (sometimes myself 
included) go so far as to say that C++ is not 'real' OO because its 
approach is too limited.

Given that, I'm not too surprised that you've had some trouble with 
ObjC. I'm not sure why it was easy for me, when I had a fairly similar 
background when I picked it up (dabbling with lisp and prolog and so on 
came later), but people who only have experience with C++-style OO do 
often have trouble properly grasping ObjC-style OO.
0
Michael
11/14/2003 8:50:10 PM
dans l'article mail-9E71C2.21254414112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 14/11/03 21:25�:

>> So it seems I'm not the only one to think that some people on this list
>> simply won't accept facts.
> 
> Perhaps, but you seem to be the only one who thinks *everyone* simply
> won't accept facts. :P

Mike, you're not being very fair. I wrote 'some'.

Eric

0
Eric
11/14/2003 9:14:27 PM
In article <BBDB0443.15792%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article mail-9E71C2.21254414112003@localhost, Michael Ash �
> mail@mikeash.com a �crit le 14/11/03 21:25�:
> 
> >> So it seems I'm not the only one to think that some people on this list
> >> simply won't accept facts.
> > 
> > Perhaps, but you seem to be the only one who thinks *everyone* simply
> > won't accept facts. :P
> 
> Mike, you're not being very fair. I wrote 'some'.

Well, you thought everybody who actually replied to you in That One 
Thread wouldn't accept facts.
0
Michael
11/14/2003 10:03:53 PM
dans l'article mail-B2DEA2.23035314112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 14/11/03 23:03�:

> Well, you thought everybody who actually replied to you in That One
> Thread wouldn't accept facts.

And that's not everybody on this list.

Eric

0
Eric
11/14/2003 11:12:37 PM
In article <droleary.usenet-30CB12.09402312112003@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
>
>> Is this because Cocoa requires Objective-C ?
>
>Cocoa has a Java API as well.  Unfortunately.

And this is the secret if you want to write portable code:
just use Java.


0
slavins
11/15/2003 1:05:10 AM
 Michael Ash <mail@mikeash.com> wrote:

> >  Michael Ash <mail@mikeash.com> wrote:
> > 
> > > Are you aware of Apple's Objective-C++ compiler, which allows you to mix 
> > > Objective-C and C++ code? This is used, for example, in Apple's WebCore, 
> > > which wraps KHTML in ObjC code to make it available for Cocoa programs.
> > 
> > So Cocoa exception macros mix with C++ exceptions by now? 
> 
> I doubt it. The new part-of-the-language exception constructs (@try, 
> @throw, etc.) are supposed to be binary-compatible with the old 
> exception macros, so I'm sure they have the same limitations.
> 
> I don't see why you would take my statement as to imply ObjC/C++ 
> exception compatibility, though. C's setjmp()/longjmp() aren't very 
> compatible with C++ objects either, but people still manage. Of course 
> you have to be careful with exceptions; if a C++ exception can be thrown 
> through Cocoa code, then you have to make sure everything is properly 
> autoreleased. If an ObjC exception can be thrown through C++ code, then 
> you have to make sure nothing bad will happen as a result of stack-based 
> objects' destructors not being called.

Setjmp is deprecated and pretty rarely used.
 
Exceptions in both environments are suggested. 

IMO, to produce nonleaking hybrid ObjC++ code with correct exception 
behavior, you need theoretically wrap all potentially throwing ObjC 
message blocks in an @try .. area, and the C++ blocks in try.. 
catch(...) blocks in order to have cleanup and dtors called. Or to find 
other paradigmns, patch GCC etc,..
Guessing "This is unlikely to happen" doesn't make the code behavior 
well-defined.

> I didn't say it was some perfect nirvana. What it *is*, is a way to mix 
> ObjC and C++. I personally find Safari to be an excellent product, so 
> obviously it is possible to produce something that works very well using 
> ObjC++.

It is, ditto with LaunchBar. 
 
> With the exception of the Finder and this newsreader, every application 
> I use on anything resembling a regular basis is a Cocoa app, both Apple 
> and third-party stuff.

My personal experience is different - YMMV. 
Mail.app crashes even at basic configuration attempts, as Keychain 
Access does when moving / copying entries. Project Builder has the 
largest CrashReporter.log on my machine even though I just tried to 
create somem samples and a simple toy application. And its "error 
handling" was definitely undefined, bad behavior. 

> and messages to nil have no effect, 

Do they? I was under the impression - using CarbonLib wraped ObjC 
objects - that [nil release]; aka CFRelease( null ); brought up a neat 
crash..

Regards,
   Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
11/15/2003 2:44:48 PM
 Michael Ash <mail@mikeash.com> wrote:

> I agree completely, but I don't see this as an ease-of-use thing, just a 
> less-typing thing. For strings, the number of operations you get 'for 
> free' with operator overloading is so small as to be insignificant. 

I wouldn't consider the design of std::string as the greatest C++ 
design. It has been pretty often critzised and is a "working compromise".

> Now, I'm not totally against operator overloading by any means. For 
> mathematical data types, I think they're great. It's very nice to be 
> able to make a vector data type or a complex number type, or some other 
> sort of numerical type where you can just write out your operations in 
> normal mathematical notation in the program.

This is the intended usage. 

> But for non-numerical 
> types, at least in C++, I think operator overloading does more harm than 
> good. Strings aren't mathematical types, so the convenience gained by 
> being able to 'add' them is very small. 

This is something also a significant number of C++ fans agree.

> > No,
> > I'm already convinced, I just feel a little frustrated it's taken
> > (taking?) longer than I expected to get up to speed. I'd like to think
> > it has more to do with the reasons I've mentioned, rather than being a
> > stoopid programmer!
> 
> Well, as I said, some people just don't seem to get it quickly, while 
> many of us do. Unlike others, I don't think it's because they're stupid. 
> But I am at a total loss to explain why.

It's not the OO style (I do use C++, Java and ObjC). 

It is about preferences, language features and needs. 

When I need to handle binary data I have a strong preference to use 
things like 
std::vector<int> and std::vector<CIntAndMore> and then an 
std::for_each() - Wrapping e.g. plain data into IntWrappers classes in 
order to put them in an ObjC or Java container is something I do not 
like at all.

When I need to handle complex XML and XSL, I have some preference to use 
Java: There _automatic_ reference-counting and Unicode-normalized string 
handling and a whole bunch of libraries brings a lot of benefits.

etc..

reagrds,
   Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
11/15/2003 3:18:28 PM
In article <bp5e50$1jgcs0$1@ID-2640.news.uni-berlin.de>,
 Thomas Engelmeier <aug03_nospam@engelmeier.com> wrote:

> Setjmp is deprecated and pretty rarely used.
>  
> Exceptions in both environments are suggested. 

Except that ObjC exceptions, at least the old macro-based variety, use 
setjmp() internally. I don't think the new-style ones use setjmp(), but 
since they're binary compatible I'm sure they have the same basic 
limitations.

> IMO, to produce nonleaking hybrid ObjC++ code with correct exception 
> behavior, you need theoretically wrap all potentially throwing ObjC 
> message blocks in an @try .. area,

This is certainly true, unless you have no stack-allocated C++ objects 
sitting around.

> and the C++ blocks in try.. 
> catch(...) blocks in order to have cleanup and dtors called.

You can safely throw C++ exceptions through ObjC code as long as all 
existing objects have a total modification to their retain counts of 
zero in that block when the potential-exception-throwing code is called. 
There really is no difference between C++ and ObjC exceptions in this 
case. As far as ObjC code is concerned, both of them jump through to 
wherever they are caught without doing anything on the way. So the 
alternative to wrapping every call into C++ land in try/catch blocks is 
to simply make sure every newly-created object is autoreleased 
beforehand. Most code does this anyway.

(One exception to the above; I'm sure that throwing a C++ exception 
won't trigger any ObjC @finally blocks.)

> Or to find 
> other paradigmns, patch GCC etc,..
> Guessing "This is unlikely to happen" doesn't make the code behavior 
> well-defined.

But you don't have to guess. Of course it takes some effort, and you 
have to pay attention to what you're doing, but you don't have to hope 
or rely on undefined behavior.

[reliability of Cocoa apps]
> My personal experience is different - YMMV. 
> Mail.app crashes even at basic configuration attempts,

I have never seen or heard of this happening. Either you're doing 
something very unusual, or your setup is broken somehow, I think. I have 
had Mail just freeze up every now and then, but not often.

> as Keychain 
> Access does when moving / copying entries.

I just tried this and it seems to work ok. I'm using 10.3.1, I never 
really used Keychain Access before.

> Project Builder has the 
> largest CrashReporter.log on my machine even though I just tried to 
> create somem samples and a simple toy application. And its "error 
> handling" was definitely undefined, bad behavior. 

PB/Xcode are very buggy programs, to be sure. But I wouldn't blame their 
bugginess on ObjC or Cocoa any more than I would blame Windows's 
bugginess on C.

> > and messages to nil have no effect, 
> 
> Do they? I was under the impression - using CarbonLib wraped ObjC 
> objects - that [nil release]; aka CFRelease( null ); brought up a neat 
> crash..

No, remember, the -release message isn't special in any way. It calls 
the ObjC messenger just like any other message. So [nil release] gets 
translated into objc_msgSend(nil, @selector(release)). objc_msgSend() 
return 0 for messages sent to nil, it doesn't even look at the selector.

There are some obscure pitfalls to this. Because objc_msgSend() has no 
information about the return value of the method, certain method types 
(I think it's anything that doesn't map to an int or pointer, such as a 
float, a 64-bit data type, or a struct) will return garbage. But for 
anything that returns an object, you are guaranteed to get nil as a 
result of sending a message to nil.
0
Michael
11/15/2003 4:37:11 PM
Thank you for your thoughts...I would like to finish up by saying:

1) I would love to make our system competely modern. Remove the cruft
or even dead code or dead resources.  That is something that I am very
vocal about.

2) I am not in a position to steer the project in a direction.  I have
always appreciated the philosphy written in many programming books
that if systems are in a bad state, you rewrite the systems piece by
piece.

3) I do not believe that I personally would be making the best
investment of my time in switching over to Cocoa.  If I had to make a
change, it would be to continue developing in a programming language
that many people use. Java, Python, etc... Something that is not
Macintosh only.  I love the Mac, but I've avoided being pigeonholed
into a proprietary language up to this point and hope to continue this
way.  In the worst case scenario that I must switch to a proprietary
language, it would be C# and .NET. Horrible as that sounds, my
perspective has switched after getting married and having to take care
of a family.  Its all programming after all (ug, I don't like Windows
look & feel).

Anyway, my original post has produced a lot of discussion. I feel
famous :)

Lyndsey Ferguson
0
lyndsey_ferguson
11/15/2003 4:43:01 PM
dans l'article edc42e1f.0311150843.6aec63b2@posting.google.com, Lyndsey
Ferguson � lyndsey_ferguson@yahoo.com a �crit le 15/11/03 17:43�:

> In the worst case scenario that I must switch to a proprietary
> language, it would be C# and .NET. Horrible as that sounds, my
> perspective has switched after getting married and having to take care
> of a family.  

It's warming to see that some people relate development to economics rather
than religion.

Good luck,

Eric

0
Eric
11/15/2003 6:24:31 PM
In article <edc42e1f.0311150843.6aec63b2@posting.google.com>,
 lyndsey_ferguson@yahoo.com (Lyndsey Ferguson) wrote:

> 3) I do not believe that I personally would be making the best
> investment of my time in switching over to Cocoa.  If I had to make a
> change, it would be to continue developing in a programming language
> that many people use. Java, Python, etc... Something that is not
> Macintosh only.  I love the Mac, but I've avoided being pigeonholed
> into a proprietary language up to this point and hope to continue this
> way.

You mixing things up. It's Cocoa that's Mac-only, not Objective-C: 
library vs. language. The Objective-C language is neither proprietary 
nor Mac-only. (You should also be aware that you're not tied to ObjC to 
write Cocoa apps, quite a few languages have been bridged to ObjC: 
Python, Ruby, Perl, Java, perhaps even more. I use PyObjC and am having 
a ball.)

Just
0
Just
11/15/2003 7:41:32 PM
In article <droleary.usenet-6565BC.11460513112003@corp.supernews.com>,
Doc O'Leary <droleary.usenet@subsume.com> wrote:

>The main reason 
>for Windows ports to a Mac failing is because they used idiot Windows 
>developers who didn't understand the Mac platform.

It's actually worse than that: they use developers who have only
ever worked on one platform.  They have no experience of anything
except one style of programming, one set of APIs, and one line of
CPUs (and therefore one machine code as a basis for everything).

They will have terrible trouble in porting to the Mac because they
have no idea of all the things that can differ between Wintel and
any other platform.


0
slavins
11/15/2003 11:39:55 PM
In article <bp5e50$1jgcs0$1@ID-2640.news.uni-berlin.de>,
 Thomas Engelmeier <aug03_nospam@engelmeier.com> wrote:

>  Michael Ash <mail@mikeash.com> wrote:
> 
> > and messages to nil have no effect, 
> 
> Do they? I was under the impression - using CarbonLib wraped ObjC 
> objects - that [nil release]; aka CFRelease( null ); brought up a neat 
> crash..

I'm not sure what a CarbonLib-wrapped Obj-C object is, but [nil release] 
is fine in Obj-C.  As Mike described, it isn't a straight thunk through 
to CFRelease.  Unfortunately, CFRelease(NULL) will crash (and, more 
unfortunately, it's supposed to behave that way).

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/15/2003 11:47:40 PM
Eric VERGNAUD wrote:
> 
> dans l'article edc42e1f.0311110824.5aa84ad1@posting.google.com, Lyndsey
> Ferguson � lyndsey_ferguson@yahoo.com a �crit le 11/11/03 17:24�:
> 
> > What would you reccommend? Please, no Cocoa discussion as my company
> > is a cross-platform company and our programmers are primarily Windows
> > people. I admit that it may be a great way to develop apps on the Mac,
> > but it is not an option here.
> 
> Is this because Cocoa requires Objective-C ? If it is, it's interesting to
> see that I'm not the only one in this group to think that Objective-C slows
> down Cocoa adoption, especially in a multiplatform context.

Eric,

Invest the three days, learn Objective-C, and *then* see if it's holding
you back.

I find that the people who object to learning Obj-C "because it's a new
language" base their opinion on the difficulty they faced in learning
C++, which is a vastly more complicated language than Obj-C.

When I swtiched from Macintosh to NeXTSTEP in 1989, I was a C++ expert,
and my Mac experience ran the gamut from writing chooser-level printer
drivers, to NuBuss configuration ROMs, to user apps.  It took me one
month to be as productive on NeXTSTEP as I had been on Macintosh, and
after about three months I could do any given task in about 1/3 of the
time on NeXT that it would have taken me on the Mac.  

That was back in 1989.  Cocoa has come a very long way from what we had
in NeXTSTEP.

-jcr
0
John
11/16/2003 2:43:27 AM
In article <f7e883a5.0311140833.5709d0b7@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> On a logical level, you're right of course. '+' doesn't do any kind of
> bizzard character munging. On a pragmatic level, you're dead wrong.
> Even newbie OO programmers are comfortable with the concept of such
> operators, it's a good idea to leverage that familiarity.

You'd think so, but I've found that is simply not the case when it comes 
to poorly overloaded operators.  It means you can't just look at:

checksum = startcode + endcode;

and know what's actually going on.  Verbose method names, especially 
those where arguments can be labeled inline like ObjC allows, are *not* 
a bad thing.

> >  More to 
> > the point, ObjC draws a very clear line between where C operations end 
> > and where object operations begin.
> 
> I don't see why that's a good thing.

Clearly.  You need to look harder.

> > Michael already responded to this pretty well, so I'll just add that you 
> > need to be specific when you point to MI as a feature, because it is a 
> > hack that is used to fill so many roles it isn't funny.  Are you doing 
> > it for simple code reuse?  Are you doing it for polymorphism?  Are you 
> > doing it because you have objects poorly defined in the design?  ObjC 
> > features make MI unnecessary for the thing most people use it for.  
> > Please detail how your needs are more advanced.
> 
> I really don't follow your logic here. MI is wrong because it's useful
> and flexible?

Flexible enough to be MISused most of the time, primarily because it is 
in languages that don't have proper support for OO concepts like 
polymorphism.  I'd still like to hear details where you think MI is the 
correct solution.

> Just because other developers find some aspects of ObjC
> counter-intuitive doesn't make them stupid either.

I'm pretty hard line in my thinking about this so I have to disagree and 
say, yeah, if you think ObjC is hard you have to be pretty dumb.  
Granted there are all kinds of smarts, and I have long maintained that 
extended use of a bad language like C++ *damages* you from an OO 
perspective.  That you struggle with ObjC likely means you need to get 
away from implementation and back to design in order to make the 
breakthrough that gets ObjC to look smooth to you instead of struggling 
with it.

> No, it's just one example of an anachronism in a Cocoa development
> tool, which forced me to waste my precious time trying to figure out
> how to perform the simplest of actions. Had it been a button and Open
> panel, it would have taken 10 seconds. Instead, it took me several
> minutes looking through sample projects. When is inconvenience ever a
> good thing?

Uh, when it allows you to do localization and dozens of other features 
that the resource lookups do.  Just because you're unfamiliar with the 
features don't make them broken or an "anachronism".  Every environment 
has a learning curve, and for whatever reason you've decided that is 
simply unacceptable for Cocoa.  The benefits people see from Cocoa are 
achieved when *they* adjust to Cocoa, not because Cocoa adjusts to them.

> This again points to your apparent willingness to resort to amateur
> psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
> toolset.

Oh, believe me, I'm well aware of areas where Cocoa/ObjC falls short.  
That is partly why I've gotten more into prototype-based OO languages 
recently, which remove the unnecessary distinction between class objects 
and instance objects.  Your complaints, however, are not fundamental 
issues like that.

> >IB 
> > is cool not because it holds your hand, but because it allows you to 
> > create and manipulate interface objects directly.  That is, when in 
> > doubt, you could check to see that NSButton has -setImage: which takes 
> > an NSImage, and NSImage has a method +imageNamed: which takes an 
> > NSString and has a documented lookup procedure.  Just because IB makes 
> > things simple is no reason to be simple minded about IB.
> 
> I didn't, because the image icon wasn't something I wanted to hard
> code.

I don't even understand what that means.  It's a named resource!  Your 
"better" solution using an open panel *would* have been using a hard 
coded file you complain about here!  You need to make up your mind about 
what you want, stop blaming others, and understand that Cocoa is based 
on over a decade of well thought out OO programming.  If it doesn't work 
the way you expect it to, that means it's your opportunity not to fight 
it, but do change your way of thinking and discover how things might be 
done better.

> (And less of the insults, eh?)

I have found that people will be as offended as they choose to be 
regardless of what I say or how I say it.  I prefer to be a jerk on the 
surface because it saves people the effort of thinking I'm being 
insincere when they act upset.  If you find yourself feeling insulted 
because you are doing wrong you should, instead of asking to not be 
corrected, start doing right.
0
Doc
11/16/2003 9:21:01 AM
 Eric Albert <ejalbert@stanford.edu> wrote:

> > Do they? I was under the impression - using CarbonLib wraped ObjC 
> > objects - that [nil release]; aka CFRelease( null ); brought up a neat 
> > crash..
> 
> I'm not sure what a CarbonLib-wrapped Obj-C object is, but [nil release] 
> is fine in Obj-C.  As Mike described, it isn't a straight thunk through 
> to CFRelease.  Unfortunately, CFRelease(NULL) will crash (and, more 
> unfortunately, it's supposed to behave that way).

Thanks for clarifying that point.

Regards,
   Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
11/16/2003 12:50:36 PM
Michael Ash <mail@mikeash.com> wrote:

>So the 
>alternative to wrapping every call into C++ land in try/catch blocks is 
>to simply make sure every newly-created object is autoreleased 
>beforehand. Most code does this anyway.

I'll check it when I get the time for it..
 
> [reliability of Cocoa apps]
 
> But I wouldn't blame their bugginess on ObjC or Cocoa any more than I would blame Windows's 
> bugginess on C.

[...] As I said, lacking representative data just based on subjective 
and empiric experiences.

> No, remember, the -release message isn't special in any way. It calls 
> the ObjC messenger just like any other message. So [nil release] gets 
> translated into objc_msgSend(nil, @selector(release)). objc_msgSend() 
> return 0 for messages sent to nil, it doesn't even look at the selector.
> 
> There are some obscure pitfalls to this. Because objc_msgSend() has no 
> information about the return value of the method, certain method types 
> (I think it's anything that doesn't map to an int or pointer, such as a 
> float, a 64-bit data type, or a struct) will return garbage. But for 
> anything that returns an object, you are guaranteed to get nil as a 
> result of sending a message to nil.

Thanks for that explaination. 

Regards,
   Tom_E

-- 
This address is valid in its unmodified form but expires soon. 

0
Thomas
11/16/2003 1:17:40 PM
In article <bp5e50$1jgcs0$1@ID-2640.news.uni-berlin.de>,
 Thomas Engelmeier <aug03_nospam@engelmeier.com> wrote:

> Setjmp is deprecated and pretty rarely used.

By whom?

I used setjmp/longjmp all the time in Un*x programs.  It's the only 
approved and guaranteed portable way to do much more than merely set a 
flag in a signal handler.

The "Gwydion" Dylan compiler uses setjmp/longjpm to implement non-local 
exits (e.g. things such as C's break & return) and therefore as the last 
step in exception handling.  (Dylan runs the exception handler before 
unwinding the stack, not after as in C++).

The "Chicken" Scheme compiler uses setjmp/longjmp as part of garbage 
collection.  Among other things, if you embed Scheme in a C program than 
this happens every time you return from a Scheme function that has been 
called from C -- which in one program of mine happens several thousand 
times a second.


About the only thing "wrong" with setjmp/longjmp is that C++ designers 
and implementators seem to have decided to work against it rather than 
working with it (and possibly extending it to call C++ destructors).  I 
can understand why it might have been that way with the original CFront, 
bit what excuse do Microsoft, Apple and GNU have, when all of them 
provide both the C++ compiler and the C library containing longjmp?

-- Bruce
0
Bruce
11/17/2003 5:18:51 AM
In article <bruce-15C203.18185117112003@copper.ipg.tsnz.net>,
 Bruce Hoult <bruce@hoult.org> wrote:

> About the only thing "wrong" with setjmp/longjmp is that C++ designers 
> and implementators seem to have decided to work against it rather than 
> working with it (and possibly extending it to call C++ destructors).

setjmp and longjmp have nothing to do with the stack unwinding and therefore it 
would be a bad idea for them to call destructors. It's equally valid to longjmp 
up a stack as it is to longjmp to a different stack (and then longjmp back to 
the original stack). In the latter case, calling destructors would be disastrous.

setjmp and longjmp are not as simple as you seem to think they are, and making 
them do the right thing is impossible, because it's impossible to usefully 
define the right thing (given the semantics of the rest of C++; you could argue 
that it's possible to have a language with different semantics that has a 
setjmp/longjump functionality that always does the right thing, but C++ is not 
that language).

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

0
Miro
11/17/2003 5:55:29 AM
Michael Ash <mail@mikeash.com> wrote in message news:<mail-0D9920.21501014112003@localhost>...
[snipped for sake of sanity..;)]

> I think operator overloading does more harm than 
> good. Strings aren't mathematical types, so the convenience gained by 
> being able to 'add' them is very small. 

We'll have to agree to disagree here then. I would have to ask what's
the harm in supporting operator overloading, when you're free to not
use them? :)

> 
> > Thanks for the info, seems I was wrong to draw a parallel between the
> > two. The concept of mix-in classes is the most useful aspect of
> > multiple inheritance to me, and seems to me to be a very OO, (i.e.
> > code reuse with minimal work involved).
> 
> I have no experience with this, so could you give me an example or two 
> of how this actually ends up working in practice? I think I get the 
> idea, but I'd like to know how it works for real.

I'm primarily a fan of these from having used PowerPlant. This link
probably describes the concept better than I can:
http://www.metrowerks.com/MW/Whitepapers/PowerPlant.htm#mixin.


> I haven't had an OS X only contract either. When you see me talking 
> about how ObjC is cross-platform, I'm not just blathering; I worked on 
> an ObjC project running on Linux and Windows for about a year and a 
> half. I only started with Cocoa later on. And let me tell you, compared 
> to Swarm (the ObjC framework I was using on that project), Cocoa is a 
> paradise of understandability, good design, and excellent documentation.

I'd have thought the name itself would serve as a warning! :)
But Cocoa is certainly growing on me. Just s-l-o-w-l-y.

> You basically pull up the "onClick" action in the interface creator 
> thingy and type your code in, right? That would be nice, but Apple is so 
> tied to ObjC and gcc, which in turn are very heavily tied to the old C 
> way of files-and-modules-and-makefiles development that I doubt this 
> will happen.

That's it. The 'outlet'-equivalent is added to the code and connected,
and the 'action' you've chosen is connected to a newly created method.
No need for merging source files, and no possibility of the source and
interface editor being out of sync.

I believe you're right; if Apple were about to go for the all in one
approach, they most likely would have done so with the introduction of
Xcode.
Still, (though I've only glanced at it) AppleScript Studio seems to be
a step in just that direction.

> Some people, (sometimes myself 
> included) go so far as to say that C++ is not 'real' OO because its 
> approach is too limited.

Sorry if this has been discussed 1/0 times before, but why wouldn't
C++ be considered an OO language? What does it lack?

Mike.
0
google
11/18/2003 6:23:17 PM
Doc O'Leary <droleary.usenet@subsume.com> wrote in message news:<droleary.usenet-FCC432.03210116112003@corp.supernews.com>...
> You'd think so, but I've found that is simply not the case when it comes 
> to poorly overloaded operators.  It means you can't just look at:
> 
> checksum = startcode + endcode;
> 
> and know what's actually going on.  Verbose method names, especially 
> those where arguments can be labeled inline like ObjC allows, are *not* 
> a bad thing.

Without knowing the types/classes, no you wouldn't know what's going
on. They might even be plain integers. So should we avoid operators
for integer
arithmatic too?

> > I don't see why that's a good thing.
> 
> Clearly.  You need to look harder.

Thanks, that was helpful. Wait! Did you write Cocoa documentation in a
past life...?

> > I really don't follow your logic here. MI is wrong because it's useful
> > and flexible?
> 
> Flexible enough to be MISused most of the time, primarily because it is 
> in languages that don't have proper support for OO concepts like 
> polymorphism.  I'd still like to hear details where you think MI is the 
> correct solution.

I don't know what 'the' correction solution is, but MI is an effective
method of code reuse with minimal effort. To use an example from
PowerPlant, the LPeriodical class, an abstract class providing support
for repeating actions. To add this functionality to one's class, you
merely add LPeriodical as a superclass, and override one method to
accomplish the task desired.

Why is this so ugly a feature it has no place in ObjC?

> > Just because other developers find some aspects of ObjC
> > counter-intuitive doesn't make them stupid either.
> 
> I'm pretty hard line in my thinking about this so I have to disagree and 
> say, yeah, if you think ObjC is hard you have to be pretty dumb.  

That's it. You ARE the guy who wrote the Cocoa documentation!

> Uh, when it allows you to do localization and dozens of other features 
> that the resource lookups do.  

What I suggested in no way impedes localization. It does however make
it easier (and thus, quicker) for developers new to the environment to
pick up. Again, why is this a bad thing?

> Just because you're unfamiliar with the 
> features don't make them broken or an "anachronism".  Every environment 
> has a learning curve, and for whatever reason you've decided that is 
> simply unacceptable for Cocoa.  The benefits people see from Cocoa are 
> achieved when *they* adjust to Cocoa, not because Cocoa adjusts to them.

In the case I provided, yes, I would consider an unintuitive (i.e why
case-sensitive? does the file need to be already in the project? what
format?), undocumented feature, reliant needlessly on typo-prone text
entry, that requires two steps in two separate applications, an
anachronism.

You obviously disagree. But then.. 5 billion non-Cocoa-programmers
can't be wrong.

> > This again points to your apparent willingness to resort to amateur
> > psychology rather than admit to ANY deficincies in ObjC, Cocoa, or the
> > toolset.
> 
> Oh, believe me, I'm well aware of areas where Cocoa/ObjC falls short.  
> That is partly why I've gotten more into prototype-based OO languages 
> recently, which remove the unnecessary distinction between class objects 
> and instance objects.  Your complaints, however, are not fundamental 
> issues like that.

Indeed. I never suggested my complaints were fundamental flaws. That
doesn't mean they can't or won't impede other developers evaluating or
beginning to adopt Cocoa.

> I don't even understand what that means.  It's a named resource!  Your 
> "better" solution using an open panel *would* have been using a hard 
> coded file you complain about here!  

Using my method, the icon could be changed in IB without requiring a
(lengthy) code rebuild simply by selecting a different file. Using
yours, I would need to rebuild the relevant code if I merely wished to
change one icon! (Unless, I used a plist setting to specify which icon
to use - which would be a good example of using a sledgehammer to swat
a fly. All I wanted to do was set one button icon!)

> I have found that people will be as offended as they choose to be 
> regardless of what I say or how I say it.  I prefer to be a jerk on the 
> surface because it saves people the effort of thinking I'm being 
> insincere when they act upset.

Indeed, your implementation may be clever, but your interface leaves a
lot to be desired.

>  If you find yourself feeling insulted 
> because you are doing wrong you should, instead of asking to not be 
> corrected, start doing right.

(see above)

Mike.
0
google
11/18/2003 7:20:30 PM
dans l'article f7e883a5.0311181023.73ac73ad@posting.google.com, Mike Whooley
� google@whooley.utvinternet.com a �crit le 18/11/03 19:23�:

>> I think operator overloading does more harm than
>> good. Strings aren't mathematical types, so the convenience gained by
>> being able to 'add' them is very small.
> 
> We'll have to agree to disagree here then. I would have to ask what's
> the harm in supporting operator overloading, when you're free to not
> use them? :)

I see no harm and many advantages. Especially when operators allow writing:

 String s1 = "message: ", s2 = "Beautiful";

 s1 += "Hello " + s2 + " World";

Without operators, this would require 3 lines of code, and be much less
readable.

It is true that allowing creation of operators can lead to inconsistent
APIs, but not allowing them doesn't make programmers more clever, does it ?

Eric

0
Eric
11/18/2003 8:19:19 PM
Hi,

For various reasons, I cannot use NSTableView. However, I'd like my view to
look like it. I cannot find which methods to use to draw column headers so
they look the same. Anyone knows how to do this either in Cocoa or using
CGContexts ?

Eric

0
Eric
11/18/2003 8:55:15 PM
In article <f7e883a5.0311181023.73ac73ad@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Michael Ash <mail@mikeash.com> wrote in message 
> news:<mail-0D9920.21501014112003@localhost>...
> [snipped for sake of sanity..;)]
> 
> > I think operator overloading does more harm than 
> > good. Strings aren't mathematical types, so the convenience gained by 
> > being able to 'add' them is very small. 
> 
> We'll have to agree to disagree here then. I would have to ask what's
> the harm in supporting operator overloading, when you're free to not
> use them? :)

Mainly the problem is that other people are still free to use them, 
including the people who write the standard libraries. So you end up 
with weird (and IMO bad) cases like using [] for dictionary lookups and 
<< and >> for file IO, in the case of C++. If everybody could be 
responsible, then I have nothing against it, but in the case of C++, 
even the language designer is irresponsible in this area.

> I'm primarily a fan of these from having used PowerPlant. This link
> probably describes the concept better than I can:
> http://www.metrowerks.com/MW/Whitepapers/PowerPlant.htm#mixin.

Do you have an example of something that mixins give you that isn't 
available in Cocoa? For example, NSTimer gives you everything 
LPeriodical gives you, and more, without needing to subclass anything. 
LPane and LCommander I'm not quite as sure about, something like 
NSResponder and NSView, I think. The dynamic nature of ObjC lets you get 
a lot of functionality without subclassing.

> I'd have thought the name itself would serve as a warning! :)
> But Cocoa is certainly growing on me. Just s-l-o-w-l-y.

I'm happy to hear it. If I can do anything to help, let me know. :)

[snip discussion of IB/Xcode potential improvements, I have nothing to 
add]

> Sorry if this has been discussed 1/0 times before, but why wouldn't
> C++ be considered an OO language? What does it lack?

Well, let's see if I can do this without starting a gigantic flame war...

The basic units of OO are the object and the message. C++ has the 
object, but not the message. In short, when you call a C++ virtual 
function, the compiler emits code that looks at a certain (hard-coded) 
index in that object's vtable, gets the function there, and calls it. 
When you invoke an ObjC method, it translates directly to a call to 
objc_msgSend(), which is a very powerful and fairly general messenger. 
So [obj method] becomes objc_msgSend(obj, @selector(method)). The basic 
sequence of actions in objc_msgSend is as follows:

Search obj's class for an implementation of 'method'.
Repeat for all of obj's superclasses until we either find one or we run 
out of superclasses.
If we found an implementation of 'method', call it, all done.
If not, call obj's forwardInvocation: so that it can handle the 
situation.

(Note that there's caching going on, so this isn't nearly as slow as it 
sounds.)

So, what's the big deal? There are several things that this lets us do 
which are impossible in a language like C++. (Anything that's not 
actually impossible, doh, please enlighten me!)

(All of the code below is real code, not pseudocode, except for the 
....'s.)

First, this allows using an object when we don't know the type:

id obj = ...;
[obj method];

You can't do this in C++ because the compiler needs to know the offset 
into the vtable at compile time, and it can't find that unless it knows 
the type of the object. If objA and objB both implement 'method' but 
have no common superclass, then you can't easily write a function that 
does the right thing and can take an instance of either objA or objB. In 
ObjC, it's trivial, I just did it above. This is useful because very 
often we don't care about the type of something, just what it's capable 
of. This is used, for example, to implement Cocoa's delegate system. 
This gets more useful later on, too....

The dynamic nature of the ObjC message send also allows you to send a 
message whose name is not known at compile time:

SEL selector = ...;
id obj = ...;
[obj performSelector:selector]; // or objc_msgSend(obj, selector);

Now we start getting into some nice, powerful stuff. We have no idea 
what method we're calling, or what kind of object we're calling it on, 
but we can still call it. Why would you want to do that? This is how 
Cocoa does actions for GUI objects. Instead of having to implement a 
particular function, or having to use a gigantic switch statement, or 
something like that, you just give tell the button, menu, etc. which 
object you want it to connect to, and what selector you want it to 
invoke.

ObjC stores a lot of information about objects and methods that is 
accessible at runtime. This removes some of the danger of calling a 
method on an object of unknown type:

id obj = ...;
if([obj respondsToSelector:@selector(method)])
   [obj method];

This only sends the 'method' message if the object actually responds to 
it. This is another piece of Cocoa's delegate system; you aren't 
required to implement every delegate method, just the ones you want. The 
object that you are being a delegate for can see which ones you've 
implemented to know which messages to send.

Those are the basics. Now we can get into some real fun, like what 
happens if you send a message that the object doesn't implement. In that 
case, as I stated above, the messenger calls the object's 
forwardInvocation: method instead. From here, you can do anything with 
the message you want.

[obj method];

This single line could call 'method' which obj implements, as usual. Or 
it could forward the message to the real object, but make the message 
execute in another thread, then forward the return value back. Or it 
could do the same thing, except the real object exists in another 
process running on another machine. (Both of these exist in Cocoa, look 
at Distributed Objects. You use the normal method sending syntax to make 
remote procedure calls.)

For some real fun, you can look at higher-order messaging. This doesn't 
exist in Cocoa, but it's available in some third-party frameworks, such 
as MPWFoundation (http://www.metaobject.com/Technology.html). The main 
concept is the trampoline, which is an object that exists only to have a 
message sent to it that it doesn't understand so that it can do 
something interesting with it. So include MPWFoundation in your project, 
then do this:

[[someArray do] method];

This will send 'method' to every element of someArray. But your method 
takes arguments. Lots of arguments. No problem!

[[someArray do] methodWithArg:x andThing:y andThing:z andStuff:q 
andBob:r];

This works as expected. But you have two arrays. You want to enumerate 
through them both, using the objects in one as the arguments to the 
other. No problem, again:

[[someArray do] methodWithObject:[otherArray each]];

Maybe you want to actually get the results. Say you want to take all the 
strings in arrayA and concatenate the strings in arrayB on to the end:

result = [[arrayA collect] stringByAppendingString:[arrayB each]];

And it goes on and on. :)

In summary, ObjC is very dynamic and has a lot of capability for 
introspection that C++ lacks, and it is these qualities that make some 
people say that C++ is not 'real' OO.
0
Michael
11/18/2003 9:49:18 PM
In article <BBE045C3.15F3E%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> For various reasons, I cannot use NSTableView. However, I'd like my view to
> look like it. I cannot find which methods to use to draw column headers so
> they look the same. Anyone knows how to do this either in Cocoa or using
> CGContexts ?

Can you embed an NSTableHeaderView in your view?
0
Michael
11/18/2003 9:50:59 PM
dans l'article mail-A00E15.22505918112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 18/11/03 22:50�:

> Can you embed an NSTableHeaderView in your view?

An idea. I'll try it.

Thanks.

Eric

0
Eric
11/18/2003 10:18:00 PM
In article <f7e883a5.0311181023.73ac73ad@posting.google.com>, Mike
Whooley <google@whooley.utvinternet.com> wrote:

> That's it. The 'outlet'-equivalent is added to the code and connected,
> and the 'action' you've chosen is connected to a newly created method.
> No need for merging source files, and no possibility of the source and
> interface editor being out of sync.

This is actually something Apple could address in Interface Builder in
the future.  WebObjects uses similar design patterns to Cocoa, and you
can add a binding (i.e. outlet) in WebObjects Builder and it
automatically gets inserted into your Java source file in Project
Builder.  And vice versa.  And you can add an action in either and it's
automatically reflected in the other.

You can even select a binding or action in WebObjects Builder and
choose "Show Source" and bring up the code in Projet Builder.

I don't know if this still works with Xcode, but I would expect it to
since Xcode 1.0 is really Project Builder 3.0.  It's just a matter of
the Interface Builder team adding similar functionality.

If you want this kind of functionality in Interface Builder and Xcode,
please file a bug at <http://bugreport.apple.com/>.

> Sorry if this has been discussed 1/0 times before, but why wouldn't
> C++ be considered an OO language? What does it lack?

Dynamic binding.  Though if it had a complete runtime, you could get
around that (which is how Cocoa Java works).

By "complete runtime" I mean the ability -- within the standard
language -- to look up and manipulate classes, methods, instance
variables, etc. entirely at run time.  In Objective-C (and Java) you
can look up a method/selector by name and invoke it.  You can get the
offset and type of an instance variable in an object.  You can traverse
the class hierarchy and find classes by name.  And so on.  About the
only thing C++ RTTI lets you do is compare classes for equality.

IB sets outlets by looking up methods (-set<OutletName>:) and instance
variables (<outletName>) at runtime.  IB sets actions by looking up
selectors at runtime.  IB instantiates objects by looking up classes at
runtime.  Etc.  Stuff that you just can't do generically in Standard
C++.

  -- Chris

-- 
Chris Hanson <cmh@bdistributed.com>
bDistributed.com, Inc.
Outsourcing Vendor Evaluation
Custom Mac OS X Development
Cocoa Developer Training
0
Chris
11/19/2003 12:04:56 AM
In article <mail-96ED26.22491818112003@localhost>,
 Michael Ash <mail@mikeash.com> wrote:

> > We'll have to agree to disagree here then. I would have to ask what's
> > the harm in supporting operator overloading, when you're free to not
> > use them? :)
> 
> Mainly the problem is that other people are still free to use them, 
> including the people who write the standard libraries. So you end up 
> with weird (and IMO bad) cases like using [] for dictionary lookups and 
> << and >> for file IO

I agree with you on << and >>.

But what on earth is wrong with using [] for dictionary lookups?  The 
built in arrays are after all just a hack optimization for the case 
where the lookup key is known in advance to be a small integer.

-- Bruce
0
Bruce
11/19/2003 12:13:31 AM
In article <f7e883a5.0311181023.73ac73ad@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Michael Ash <mail@mikeash.com> wrote in message 
> news:<mail-0D9920.21501014112003@localhost>...
> [snipped for sake of sanity..;)]
> 
> > I think operator overloading does more harm than 
> > good. Strings aren't mathematical types, so the convenience gained by 
> > being able to 'add' them is very small. 
> 
> We'll have to agree to disagree here then. I would have to ask what's
> the harm in supporting operator overloading, when you're free to not
> use them? :)

Other people do, though, and if you end up maintaining someone else's 
source you have to make either greater assumptions or greater efforts to 
validate their sanity.

Consider: If you have two strings s = "Foo", t = "Bar" then s+t 
obviously is "FooBar", right? But what if s="3" and t = "4"? Does s+t = 
"34" or did someone get clever make make the result "7"?

G (Who, in fact, doesn't mind operator overloading, but understands and 
respects others objections to it.)
0
Gregory
11/19/2003 1:56:23 AM
dans l'article gwestonREMOVE-27EE01.20562118112003@netnews.attbi.com,
Gregory Weston � gwestonREMOVE@CAPSattbi.com a �crit le 19/11/03 2:56�:

> Consider: If you have two strings s = "Foo", t = "Bar" then s+t
> obviously is "FooBar", right? But what if s="3" and t = "4"? Does s+t =
> "34" or did someone get clever make make the result "7"?

You could place this objection on ANY method, whether operator or not. In
the above example, replace operator+ by Append. s.Append(t) could very well
produce "7" instead of "34". You can't prevent programmers from being
stupid, can you ? So why prevent them from being clever ? That's one of the
things I hate in Java. Garbage collection is indeed very useful and doesn't
harm anyone, but why in the hell can't we have a few global variables, a few
standalone methods, and operator overloading ?

Eric

0
Eric
11/19/2003 8:56:19 AM
In article <bruce-8B4B37.13133119112003@copper.ipg.tsnz.net>,
 Bruce Hoult <bruce@hoult.org> wrote:

> In article <mail-96ED26.22491818112003@localhost>,
>  Michael Ash <mail@mikeash.com> wrote:
> 
> > > We'll have to agree to disagree here then. I would have to ask what's
> > > the harm in supporting operator overloading, when you're free to not
> > > use them? :)
> > 
> > Mainly the problem is that other people are still free to use them, 
> > including the people who write the standard libraries. So you end up 
> > with weird (and IMO bad) cases like using [] for dictionary lookups and 
> > << and >> for file IO
> 
> I agree with you on << and >>.
> 
> But what on earth is wrong with using [] for dictionary lookups?  The 
> built in arrays are after all just a hack optimization for the case 
> where the lookup key is known in advance to be a small integer.

What happens when I use [] with a key that doesn't exist in my 
dictionary?  Does it return NULL?  Does it create that key with a 
default value?  Does it raise an exception?

It's possible to declare that it'll behave in a certain way, of course, 
but that'll be different from how it behaves in other languages that 
provide the same overloaded construct, and it'll be different from using 
[] as the array index operator.

-Eric, who doesn't feel strongly either way on operator overloading but 
recognizes that there are problems with it

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/19/2003 9:14:31 AM
In article <BBE0EEC3.15F6F%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article gwestonREMOVE-27EE01.20562118112003@netnews.attbi.com,
> Gregory Weston � gwestonREMOVE@CAPSattbi.com a �crit le 19/11/03 2:56�:
> 
> > Consider: If you have two strings s = "Foo", t = "Bar" then s+t
> > obviously is "FooBar", right? But what if s="3" and t = "4"? Does s+t =
> > "34" or did someone get clever make make the result "7"?
> 
> You could place this objection on ANY method, whether operator or not. In
> the above example, replace operator+ by Append. s.Append(t) could very well
> produce "7" instead of "34". You can't prevent programmers from being
> stupid, can you ? So why prevent them from being clever ? That's one of the
> things I hate in Java. Garbage collection is indeed very useful and doesn't
> harm anyone, but why in the hell can't we have a few global variables, a few
> standalone methods, and operator overloading ?

You just described Python. Why complain about Java if there are great 
alternatives?

Just
0
Just
11/19/2003 9:21:29 AM
dans l'article just-70FCA3.10212719112003@news1.news.xs4all.nl, Just �
just@xs4all.nl a �crit le 19/11/03 10:21�:

> You just described Python. Why complain about Java if there are great
> alternatives?

The decision to use Java is often a customer's decision, so I have to use
it. Java is a de facto standard, so is C++, that's why I complain about some
Java restrictions, and the unavailibility of a C/C++ API for Cocoa.

Where can I have a look at Python ?
Eric

0
Eric
11/19/2003 9:43:15 AM
In article <BBE0F9C3.15FC8%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article just-70FCA3.10212719112003@news1.news.xs4all.nl, Just �
> just@xs4all.nl a �crit le 19/11/03 10:21�:
> 
> > You just described Python. Why complain about Java if there are great
> > alternatives?
> 
> The decision to use Java is often a customer's decision, so I have to use
> it.

Tough luck.

> Java is a de facto standard, so is C++, that's why I complain about some
> Java restrictions, and the unavailibility of a C/C++ API for Cocoa.

From the entire thread I'm sure by now you understand that C/C++ are 
simply not dynamic enough for Cocoa. Apparently Java is just about 
dynamic enough, but just barely, it's apparently not a natural fit. More 
dynamic languages fit much better, such as Python or Ruby.

Btw. I agree with you that Cocoa can be hard: it took me quite some time 
to get to grips with how Cocoa does things, for example how code 
interacts with nib files. You need to "get" it before you can be truly 
productive, and that can take time. On the other hand, I found 
Objective-C dead easy to pick up, but having experience with a truly 
dynamic language (Python in my case) helps a lot.

> Where can I have a look at Python ?

Python the language:
  http://www.python.org/

ObjC/Cocoa bridge:
  http://pyobjc.sf.net/

Python on the Mac:
  http://pythonmac.org/

Btw. Jaguar ships with Python 2.2, but it's highly recommended to 
install 2.3, Panther ships with 2.3.

Just
0
Just
11/19/2003 10:31:34 AM
>> The decision to use Java is often a customer's decision, so I have to use
>> it.
> 
> Tough luck.

Well, I love Java, although I prefer C++. I'm not 100% satisfied with Java,
but I find it great for non-graphical work, notably because it's so stable
and multiplatform.

> From the entire thread I'm sure by now you understand that C/C++ are
> simply not dynamic enough for Cocoa. Apparently Java is just about
> dynamic enough, but just barely, it's apparently not a natural fit.

As for C/C++, I still don't understand why some people on this list think
it's not possible to provice a C/C++ API. I'm doing it myself, as a layer
above Obj-C. Obviously it doesn't give all the flexibility Cocoa gives
(notably subclassing), but if I can do it, why is not possible ? All I'm
talking about is a set of C routines to create UI objects and control them,
something that would really help Cocoa newcomers who are afraid of or can't
afford learning Obj-C, very much like JDOM makes XML easy. If that set of
routines was open-source, it would certainly help programmers to adopt
Cocoa, understand it, get familiar with Obj-C, and in the end switch to it.

> On the other hand, I found Objective-C dead easy to pick up, but having
> experience with a truly dynamic language (Python in my case) helps a lot.

So did I. But then I remember it took me some time to *make the decision* to
use it, because I was faced with many obstacles:
 - learning a new language, without knowing *before* how hard it would be
 - have all obj-c code in a separate module since I can't compile obj-c with
Visual C++
 - completely change the event model in my app
 - completely rewrite the implementation of my UI wrapper objects
My intention was to point the fact that some of these obstacles could be
removed, thus accelerating Cocoa adoption. Apparently, some people on this
list thought I was having a hard time with Obj-C. Never mind.

> Btw. I agree with you that Cocoa can be hard: it took me quite some time
> to get to grips with how Cocoa does things, for example how code
> interacts with nib files. You need to "get" it before you can be truly
> productive, and that can take time.

In fact, Cocoa is so tightly bound to IB that it makes it difficult to
understand it *without* using IB. Notably the concept of file owner is very
hard. Having to use IB was definitely a problem for me, since for historical
reasons, the UI in my apps is created dynamically by the framework.  Apple
has put a lot of focus on apps designed with IB, which participates in what
I call forcing the programmer into a programming model. I don't usually
start my developments with the UI. This may be unusual, but I feel much more
comfortable when the data objects I need to deal with are in place, with all
their methods, and the UI objects are only displayers and accessors for
these objects and their actions. That's one thing I don't like in Cocoa: the
UI is too tightly connected to the actions, I'd like to have an option where
a control or menu can simply send a valued message (like the menu item tag)
to the app or the first responder.

> More dynamic languages fit much better, such as Python or Ruby.

Well Python is interpreted as I understand, so that certainly has an impact
on performance. 

Eric

0
Eric
11/19/2003 2:02:08 PM
In article <BBE13670.16019%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> > More dynamic languages fit much better, such as Python or Ruby.
> 
> Well Python is interpreted as I understand, so that certainly has an impact
> on performance. 
> 

It all depends on what you are doing with it - there are a ton of 
"native" extensions (including various matrix math and image packages, 
and well, when using Cocoa, the entire UI) so the scripting code acts 
more like glue connecting native code, so things aren't as slow as you'd 
suspect.

From a literal sense, yes, it does have an impact on performance, but 
from a practical one, not so much (for many things).
0
Glenn
11/19/2003 3:17:55 PM
In article <BBE13670.16019%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> As for C/C++, I still don't understand why some people on this list think
> it's not possible to provice a C/C++ API. I'm doing it myself, as a layer
> above Obj-C. Obviously it doesn't give all the flexibility Cocoa gives
> (notably subclassing), but if I can do it, why is not possible ? All I'm
> talking about is a set of C routines to create UI objects and control them,
> something that would really help Cocoa newcomers who are afraid of or can't
> afford learning Obj-C, very much like JDOM makes XML easy. If that set of
> routines was open-source, it would certainly help programmers to adopt
> Cocoa, understand it, get familiar with Obj-C, and in the end switch to it.

So how does your C API handle things like IB outlets, setting actions 
for buttons, signing up for notifications and timers, distributed 
objects, archiving, undo, delegation, the responder chain, custom views, 
and table/outline view callbacks?

Not that all of these are impossible, but they are some difficult points 
that I can think of offhand. And even if you can provide a good API, you 
won't be providing anything remotely like Cocoa. You'll be providing 
Random-C-API-Which-Uses-Cocoa. Understanding subclassing, delegation, 
the responder chain, and the ObjC runtime is critical to understanding 
Cocoa, so I don't see how this API will help people adopt to Cocoa. They 
won't be any closer to understanding those concepts after learning some 
vaguely-related C API.

> Having to use IB was definitely a problem for me, since for historical
> reasons, the UI in my apps is created dynamically by the framework.  Apple
> has put a lot of focus on apps designed with IB, which participates in what
> I call forcing the programmer into a programming model.

It's just as easy to create an interface in code from Cocoa as it is in 
any other API I'm familiar with. Just because IB exists and everybody 
uses it doesn't mean you're forced to use it. There's nothing IB does 
that you can't do yourself, from code, with not too much effort.

> I don't usually
> start my developments with the UI. This may be unusual, but I feel much more
> comfortable when the data objects I need to deal with are in place, with all
> their methods, and the UI objects are only displayers and accessors for
> these objects and their actions.

That sounds normal enough. I still don't see how providing IB makes this 
approach more difficult than usual.

> That's one thing I don't like in Cocoa: the
> UI is too tightly connected to the actions, I'd like to have an option where
> a control or menu can simply send a valued message (like the menu item tag)
> to the app or the first responder.

Um, is this really so difficult to do yourself? Connect each menu item 
or control to "ericsAggregatorMethodThing:". Have that method get the 
control's tag and do whatever it is you want to do with the tag. For 
bonus points, have your NSApp delegate and window controllers search for 
all menu items and controls that don't already have an action and hook 
them up to that action, so you don't have to hook them all up yourself 
in IB.

These last two problems (code-created GUI objects, valued messages) are 
very strange to me; in both cases, Cocoa provides extra flexability, but 
you aren't forced to use it.
0
Michael
11/19/2003 6:49:33 PM
>> As for C/C++, I still don't understand why some people on this list think
>> it's not possible to provice a C/C++ API. I'm doing it myself, as a layer
>> above Obj-C. Obviously it doesn't give all the flexibility Cocoa gives
>> (notably subclassing), but if I can do it, why is not possible ? All I'm
>> talking about is a set of C routines to create UI objects and control them,
>> something that would really help Cocoa newcomers who are afraid of or can't
>> afford learning Obj-C, very much like JDOM makes XML easy. If that set of
>> routines was open-source, it would certainly help programmers to adopt
>> Cocoa, understand it, get familiar with Obj-C, and in the end switch to it.
> 
> So how does your C API handle things like IB outlets, setting actions
> for buttons, signing up for notifications and timers, distributed
> objects, archiving, undo, delegation, the responder chain, custom views,
> and table/outline view callbacks?

Through C callbacks.

> Not that all of these are impossible, but they are some difficult points
> that I can think of offhand. And even if you can provide a good API, you
> won't be providing anything remotely like Cocoa. You'll be providing
> Random-C-API-Which-Uses-Cocoa. Understanding subclassing, delegation,
> the responder chain, and the ObjC runtime is critical to understanding
> Cocoa, so I don't see how this API will help people adopt to Cocoa. They
> won't be any closer to understanding those concepts after learning some
> vaguely-related C API.

Well Michael you know I don't agree with you on this subject. For *some*
programmers, it's more comfortable to start with a subset of the API, gain
confidence, trace the code, understand what a target and an action are,
understand what a delegate is, and when they feel confident enough, move on.

>> Having to use IB was definitely a problem for me, since for historical
>> reasons, the UI in my apps is created dynamically by the framework.  Apple
>> has put a lot of focus on apps designed with IB, which participates in what
>> I call forcing the programmer into a programming model.
> 
> It's just as easy to create an interface in code from Cocoa as it is in
> any other API I'm familiar with. Just because IB exists and everybody
> uses it doesn't mean you're forced to use it. There's nothing IB does
> that you can't do yourself, from code, with not too much effort.

Well you're not familiar with Win32, or you wouldn't say that, since there
are many things you need to set in order to get a Cocoa UI to work: target,
action, delegate... Not speaking of the already discussed setVisible method.
The objects themselves are sometimes much more complex to create: for
example, for a scrollable text view, in Windows, all you need is to create a
RichEdit window. It requires much more work to do the same in Cocoa, while
it's very simple in IB. Of course, once it's done, it sounds easy, because
it's only 10 lines of code. What I'm talking about is the time it takes to
find the lines (don't tell me you know them by heart). In Win32, the
paradigm is the same for all UI objects: override the WindowProc, so once
you've learned that, you know how to do anytrhing. In Carbon, the event
handlers are quite the same concept. In Cocoa, each object has its own
methods for doing things. Example: to set the text of an object in Win32,
you call SetWindowText. This is true for ANY window class. In Cocoa, for a
button, you call setTitle, for a label you call setStringValue. Yes, it's
easy. But in the end, it takes much more time to understand and learn.

>> I don't usually
>> start my developments with the UI. This may be unusual, but I feel much more
>> comfortable when the data objects I need to deal with are in place, with all
>> their methods, and the UI objects are only displayers and accessors for
>> these objects and their actions.
> 
> That sounds normal enough. I still don't see how providing IB makes this
> approach more difficult than usual.

>> That's one thing I don't like in Cocoa: the
>> UI is too tightly connected to the actions, I'd like to have an option where
>> a control or menu can simply send a valued message (like the menu item tag)
>> to the app or the first responder.
> 
> Um, is this really so difficult to do yourself? Connect each menu item
> or control to "ericsAggregatorMethodThing:". Have that method get the
> control's tag and do whatever it is you want to do with the tag. For
> bonus points, have your NSApp delegate and window controllers search for
> all menu items and controls that don't already have an action and hook
> them up to that action, so you don't have to hook them all up yourself
> in IB.

Michael, I *AM* doing this. But I regret that I have to do it. In Carbon,
you receive the tag in your event handler, without any effort. In Win32, you
receive a WM_COMMAND in your window proc, without any effort. Why do I have
to make an effort to get the same behaviour in Cocoa ? It's not *THAT*
difficult. It's just more difficult, because it requires more work.

> These last two problems (code-created GUI objects, valued messages) are
> very strange to me; in both cases, Cocoa provides extra flexability, but
> you aren't forced to use it.

You have to do it the Cocoa way. And it's a way which does not fit all
programmers. Everything is feasible. I managed to do it. Cocoa is I think
very productive when you write an app from scratch. But if you're porting
existing Carbon or Win32 code, it requires a lot of work, much more than
porting from Carbon to Win32 or vice-versa.

Do you have an example of an app written for Cocoa that has been
successfully ported to Windows without a complete rewrite ?

Eric 

0
Eric
11/19/2003 7:57:37 PM
In article <BBE189C1.16086%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> > So how does your C API handle things like IB outlets, setting actions
> > for buttons, signing up for notifications and timers, distributed
> > objects, archiving, undo, delegation, the responder chain, custom views,
> > and table/outline view callbacks?
> 
> Through C callbacks.

Maybe it's just impossible to convince me, but I have a really hard time 
believing that you can provide a reasonable subset of capabilities this 
way. I don't doubt that you've provided enough of a subset for what you 
need; what I doubt is that what you've managed to do is enough for a 
general-purpose API.

> Well Michael you know I don't agree with you on this subject. For *some*
> programmers, it's more comfortable to start with a subset of the API, gain
> confidence, trace the code, understand what a target and an action are,
> understand what a delegate is, and when they feel confident enough, move on.

But what you're proposing isn't a subset of Cocoa, it's a completely 
different API. Or are you proposing that they write the program with the 
C APIs first, then gradually move pieces over to ObjC?

[ease of creation of objects in code]
> Well you're not familiar with Win32, or you wouldn't say that, since there
> are many things you need to set in order to get a Cocoa UI to work: target,
> action, delegate... [snip] Yes, it's
> easy. But in the end, it takes much more time to understand and learn.

You're right that I'm not familiar with Win32. And I will concede this 
point.

> > Um, is this really so difficult to do yourself? Connect each menu item
> > or control to "ericsAggregatorMethodThing:". Have that method get the
> > control's tag and do whatever it is you want to do with the tag. For
> > bonus points, have your NSApp delegate and window controllers search for
> > all menu items and controls that don't already have an action and hook
> > them up to that action, so you don't have to hook them all up yourself
> > in IB.
> 
> Michael, I *AM* doing this. But I regret that I have to do it. In Carbon,
> you receive the tag in your event handler, without any effort. In Win32, you
> receive a WM_COMMAND in your window proc, without any effort. Why do I have
> to make an effort to get the same behaviour in Cocoa ? It's not *THAT*
> difficult. It's just more difficult, because it requires more work.

Let's see, [sender tag], that's eleven characters. That seems close 
enough to "you receive the tag in your event handler" to me. Of course, 
you still have to hook things up, if that's what you're talking about.

Of course, the whole target/action thing is fundamental to the way Cocoa 
works. This is why we keep thinking that you don't really want Cocoa, 
you just want a slightly better Carbon.

> > These last two problems (code-created GUI objects, valued messages) are
> > very strange to me; in both cases, Cocoa provides extra flexability, but
> > you aren't forced to use it.
> 
> You have to do it the Cocoa way. And it's a way which does not fit all
> programmers. Everything is feasible. I managed to do it. Cocoa is I think
> very productive when you write an app from scratch. But if you're porting
> existing Carbon or Win32 code, it requires a lot of work, much more than
> porting from Carbon to Win32 or vice-versa.

Well, when you write Carbon apps, you're forced to do things the Carbon 
way, and I'm sure Win32 forces you into the Win32 way.

> Do you have an example of an app written for Cocoa that has been
> successfully ported to Windows without a complete rewrite ?

I would have trouble naming any Windows app not written by Microsoft, so 
I have to pass on this one.
0
Michael
11/19/2003 8:38:15 PM
In article <BBE0EEC3.15F6F%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article gwestonREMOVE-27EE01.20562118112003@netnews.attbi.com,
> Gregory Weston � gwestonREMOVE@CAPSattbi.com a �crit le 19/11/03 2:56�:
> 
> > Consider: If you have two strings s = "Foo", t = "Bar" then s+t
> > obviously is "FooBar", right? But what if s="3" and t = "4"? Does s+t =
> > "34" or did someone get clever make make the result "7"?
> 
> You could place this objection on ANY method, whether operator or not.

Yes, but there's a disconnect between what people _can_ do and what 
people _do_. No sane person would overload a method named Append() to do 
anything other than attach one thing to the end of another. But + 
doesn't mean "append;" it means "add." What's "add" mean in the context 
of a string?

As I said, I don't generally have a problem with operator overloading. 
But if you look around a bit, I think you'll find that for most of the 
people that _do_ their objection isn't academic. Most of them have run 
into just the sort of obfuscatory "cleverness" I described.

G
0
Gregory
11/19/2003 10:36:35 PM
dans l'article mail-01BE9B.21381519112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 19/11/03 21:38�:

>>> So how does your C API handle things like IB outlets, setting actions
>>> for buttons, signing up for notifications and timers, distributed
>>> objects, archiving, undo, delegation, the responder chain, custom views,
>>> and table/outline view callbacks?
>> 
>> Through C callbacks.
> 
> Maybe it's just impossible to convince me, but I have a really hard time
> believing that you can provide a reasonable subset of capabilities this
> way. I don't doubt that you've provided enough of a subset for what you
> need; what I doubt is that what you've managed to do is enough for a
> general-purpose API.

Well I never said it was, it's for UI only. I said it was feasible, and that
if Apple invested enough resources, they could very well come up with a
subset with enough consistency to compete with Carbon, thus providing an
easy move to Carbon developers. And the nice thing about it is that since
Cocoa windows support Carbon controls, the developers could do it at their
pace.

I understand your point about messaging and introspection. I've used
introspection in Java and I find it very powerful and useful. But how many
apps really need this language feature ? Don't kill me if I say that in the
apps that don't, from a programmer's standpoint, writing
MyObj->DoSomething() (in C++), MyObj.DoSomething() (in Java) and [MyObj
doSomething] (in Obj-C) are exactly the same, even though the underlying
concepts are different. It's more a runtime issue than a programming issue,
don't you think ?

>> Well Michael you know I don't agree with you on this subject. For *some*
>> programmers, it's more comfortable to start with a subset of the API, gain
>> confidence, trace the code, understand what a target and an action are,
>> understand what a delegate is, and when they feel confident enough, move on.
> 
> But what you're proposing isn't a subset of Cocoa, it's a completely
> different API. Or are you proposing that they write the program with the
> C APIs first, then gradually move pieces over to ObjC?

Yes, exactly, that's what I'm proposing. It's a different API, but it relies
on Cocoa, so Cocoa is there. All it does is things like the following:

struct  XCallbacks;

NSControlRef CocoaCreateButton(XCallbacks* inCallbacks,long inType,long
inStyle)
{
    NSRect rect = { { 0, 0 }, { 0, 0 } };
    // XCocoaButton is a NSButton with callbacks, and its own target
    XCocoaButton* ref = [[XCocoaButton alloc] initWithFrame:rect];
    [ref setCallbacks:inCallbacks];
    [ref setButtonType:(NSButtonType)inType];
    [ref setBezelStyle:(NSBezelStyle)inStyle];
    // send events to controlActioned method, which calls the C callback
    [ref setTarget:ref];
    [ref setAction:@selector(controlActioned:)];
    return ref;
}

With this kind of API, it becomes very easy for a Windows or a Carbon
programmer to call this method, rather than CreatePushButtonControl (in
Carbon) or CreateWindowEx (in Win32).

Now imagine that the above code was provided as open-source for all existing
Cocoa UI objects. Don't you think many Carbon developers would easily switch
to Cocoa ? Don't you think that, being able to trace that code, including
the callbacks, they'd get a step by step understanding on what's really
going on out there ?

>>> Um, is this really so difficult to do yourself? Connect each menu item
>>> or control to "ericsAggregatorMethodThing:". Have that method get the
>>> control's tag and do whatever it is you want to do with the tag. For
>>> bonus points, have your NSApp delegate and window controllers search for
>>> all menu items and controls that don't already have an action and hook
>>> them up to that action, so you don't have to hook them all up yourself
>>> in IB.
>> 
>> Michael, I *AM* doing this. But I regret that I have to do it. In Carbon,
>> you receive the tag in your event handler, without any effort. In Win32, you
>> receive a WM_COMMAND in your window proc, without any effort. Why do I have
>> to make an effort to get the same behaviour in Cocoa ? It's not *THAT*
>> difficult. It's just more difficult, because it requires more work.
> 
> Let's see, [sender tag], that's eleven characters. That seems close
> enough to "you receive the tag in your event handler" to me. Of course,
> you still have to hook things up, if that's what you're talking about.

Yes, and to 'hook things up', you need a class to be the delegate and/or the
target, and set the action for it. That's significantly more than 11
characters, and you end up doing this for every single UI object in Cocoa,
because Obj-C won't support multiple inheritance.

Currently, if a control or menuitem has no associated action, nothing
happens, the message is lost. Cocoa could very well provide a mechanism like
the following:

 -(bool)actionTriggered:(id)anObject tag:(int)aTag;

that would by default forward the message to the superview, the first
responder or the app delegate. That method would be called whenever the
control or the menu item has no associated action.

> Of course, the whole target/action thing is fundamental to the way Cocoa
> works. This is why we keep thinking that you don't really want Cocoa,
> you just want a slightly better Carbon.

Advanced UI objects, preemptive threads, that's more than slightly better,
don't you think ? Yes, if they'd been available in Carbon, I wouldn't have
switched to Cocoa, but after weeks of fighting with bogus HIScrollViews,
bogus Textension (yes, i know it's solved in 10.3), and bogus MPRemoteCall,
I thought I'd better spend my energy in a much more stable environment. And
I'm very glad I did. Cocoa is indeed much better than Carbon, and Quartz
better than Quickdraw. But Cocoa requires more work in my case. If I had no
code to reuse, and no portability issue, maybe I'd write it completely in
Obj-C using Cocoa classes, but the thing is, I have 3 MB of library code
written in C and C++, and portability *is* a main concern.

>>> These last two problems (code-created GUI objects, valued messages) are
>>> very strange to me; in both cases, Cocoa provides extra flexability, but
>>> you aren't forced to use it.
>> 
>> You have to do it the Cocoa way. And it's a way which does not fit all
>> programmers. Everything is feasible. I managed to do it. Cocoa is I think
>> very productive when you write an app from scratch. But if you're porting
>> existing Carbon or Win32 code, it requires a lot of work, much more than
>> porting from Carbon to Win32 or vice-versa.
> 
> Well, when you write Carbon apps, you're forced to do things the Carbon
> way, and I'm sure Win32 forces you into the Win32 way.

Yes, you're right. But since they're very close, and both available in C,
it's not a big deal. The thing is, the Win32 event model has been up for 15
years, like many other system APIs. So probably 99% of the graphical apps
around follow this model. I'm not saying it's better. It's just part of
history.

>> Do you have an example of an app written for Cocoa that has been
>> successfully ported to Windows without a complete rewrite ?
> 
> I would have trouble naming any Windows app not written by Microsoft, so
> I have to pass on this one.

Well you see, we have very different standpoints. Windows portability is a
major concern for me. And I'm pretty sure I'm not the only guy around having
to deal with that issue, since my customers can't afford paying twice the
development. Maybe that's why I think many programmers share my ideas on
Cocoa adoption - extrapolating again.

Eric

0
Eric
11/19/2003 11:35:52 PM
In article <f7e883a5.0311181120.4acdeb26@posting.google.com>,
 google@whooley.utvinternet.com (Mike Whooley) wrote:

> Doc O'Leary <droleary.usenet@subsume.com> wrote in message 
> news:<droleary.usenet-FCC432.03210116112003@corp.supernews.com>...
> > You'd think so, but I've found that is simply not the case when it comes 
> > to poorly overloaded operators.  It means you can't just look at:
> > 
> > checksum = startcode + endcode;
> 
> Without knowing the types/classes, no you wouldn't know what's going
> on. They might even be plain integers. So should we avoid operators
> for integer arithmatic too?

That doesn't make sense.  The mathematic operators are *defined* by 
their operations on numbers.  What + means for integers is not in 
question.  What raises questions is what + means for strings (especially 
strings that happen to be numbers) and, once you *allow* it to be used 
with neither rhyme nor reason for non-numeric types, there is a question 
of what the standalone + could mean at all.

> I don't know what 'the' correction solution is, but MI is an effective
> method of code reuse with minimal effort. To use an example from
> PowerPlant, the LPeriodical class, an abstract class providing support
> for repeating actions. To add this functionality to one's class, you
> merely add LPeriodical as a superclass, and override one method to
> accomplish the task desired.
> 
> Why is this so ugly a feature it has no place in ObjC?

You are confusing a higher level operation with a language/library level 
implementation.  As has been pointed out, Cocoa provides NSTimer objects 
and does not need MI to do it.  It's not a question of whether or not a 
periodic task is handy, it's a question of whether that is a feature of 
MI.  It clear is not.  I am still waiting for an example that shows is 
MI necessary for anything, save to hack a borderline OO language like 
C++ to be somewhat (re)usable.

> 
> > > Just because other developers find some aspects of ObjC
> > > counter-intuitive doesn't make them stupid either.
> > 
> > I'm pretty hard line in my thinking about this so I have to disagree and 
> > say, yeah, if you think ObjC is hard you have to be pretty dumb.  
> 
> That's it. You ARE the guy who wrote the Cocoa documentation!

I'd rather not drift the topic.  Cocoa is a library and if you want to 
compare libraries, start talking about the C++ STL.  I'm more interested 
in the features of the base language.  ObjC is, at the core, very simple 
and doesn't need a thick book or volumes of documentation.  Cocoa builds 
on those feature, but just as any library would build on their 
respective base languages, and likewise creates an additional learning 
curve.  So I'm now left at a loss to understand if you have an ObjC 
problem or a Cocoa problem.

> > Uh, when it allows you to do localization and dozens of other features 
> > that the resource lookups do.  
> 
> What I suggested in no way impedes localization. It does however make
> it easier (and thus, quicker) for developers new to the environment to
> pick up. Again, why is this a bad thing?

Please describe to me how specifying the full path to a file aids in 
localization compared to using a named identifier.  Further explain to 
me how selecting files aids a new developer in understanding resource 
location.

> In the case I provided, yes, I would consider an unintuitive (i.e why
> case-sensitive? does the file need to be already in the project? what
> format?), undocumented feature, reliant needlessly on typo-prone text
> entry, that requires two steps in two separate applications, an
> anachronism.

What you call an anachronism I call decoupling, and it is a *huge* win 
from a development perspective.  It allows the people who understand 
user interface issues to work within their area of expertise and it 
allows coders to work within their area of expertise.  It's almost as if 
your complaint is that the tools Apple gives you for free are too 
powerful for what you do.  If so, fine, but stop trying to convince that 
what your limited tool do for you is sufficient what we need done for us.

> You obviously disagree. But then.. 5 billion non-Cocoa-programmers
> can't be wrong.

Yes, and DOS must have been the most advanced OS for its time.  Now hows 
about you go play with idiots who will actually buy a "popular == good" 
argument?  The Mac is not a majority platform *whatever* you use; you 
are free to leave if you think the numbers are better elsewhere.

> Indeed. I never suggested my complaints were fundamental flaws. That
> doesn't mean they can't or won't impede other developers evaluating or
> beginning to adopt Cocoa.

Then let them struggle.  They're most likely fighting their own bad 
practices and not hampered by what Cocoa offers.  If they don't have the 
OO background to understand what they're getting, there isn't a lot that 
can be done at a language or library level to correct them.

> Using my method, the icon could be changed in IB without requiring a
> (lengthy) code rebuild simply by selecting a different file. Using
> yours, I would need to rebuild the relevant code if I merely wished to
> change one icon! (Unless, I used a plist setting to specify which icon
> to use - which would be a good example of using a sledgehammer to swat
> a fly. All I wanted to do was set one button icon!)

What the hell are you talking about?  It's sounding more and more like 
you've never used the tools at all.  If the image is a named resource, 
you simply give the second image the name and it'll be used.  That's why 
localization works without having to recompile anything!  Honestly, your 
need to know what your talking about before you throw out wild 
complaints because it's making you look real bad.

I'm sorry if you're finding proper development to be outside your 
previous experience.  The proper solution is not for the tools to be 
crippled to suit you, but for you to get up to speed and change your 
practices so that you can take advantage of the tools given to you.

> > I have found that people will be as offended as they choose to be 
> > regardless of what I say or how I say it.  I prefer to be a jerk on the 
> > surface because it saves people the effort of thinking I'm being 
> > insincere when they act upset.
> 
> Indeed, your implementation may be clever, but your interface leaves a
> lot to be desired.

Just as with Cocoa, you are free to use your own interface of you don't 
like the one provided.  The underlying framework of ideas is the same, 
and either you find it useful or you don't.  I've got no investment, 
aside from sympathy, in your mindset whichever way you choose.
0
Doc
11/20/2003 12:53:34 AM
dans l'article mail-A00E15.22505918112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 18/11/03 22:50�:

> In article <BBE045C3.15F3E%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> For various reasons, I cannot use NSTableView. However, I'd like my view to
>> look like it. I cannot find which methods to use to draw column headers so
>> they look the same. Anyone knows how to do this either in Cocoa or using
>> CGContexts ?
> 
> Can you embed an NSTableHeaderView in your view?

That was not possible, because NSTableHeaderView  needs a NSTableView.
However it gave me the idea to use NSTableHeaderCell. Was pretty tough since
there is no NSTableHeader control, however by subclassing NSButton and
NSButtonCell, and calling NSTableHeaderCell's draw methods instead
NSButtonCell's draw methods, I got it working. Found very strange things
such as:
 - NSTableHeaderCell won't draw properly if the control is not flipped
 - NSTableHeaderCell won't hilite when its state is on, so you need to call
highlight instead of drawWithFrame
 - stopTracking is never called at the end of a tracking session

Eric

0
Eric
11/20/2003 2:31:23 AM
In article <ejalbert-4BEF36.01143119112003@news.stanford.edu>,
 Eric Albert <ejalbert@stanford.edu> wrote:

> In article <bruce-8B4B37.13133119112003@copper.ipg.tsnz.net>,
>  Bruce Hoult <bruce@hoult.org> wrote:
> 
> > In article <mail-96ED26.22491818112003@localhost>,
> >  Michael Ash <mail@mikeash.com> wrote:
> > 
> > > > We'll have to agree to disagree here then. I would have to ask what's
> > > > the harm in supporting operator overloading, when you're free to not
> > > > use them? :)
> > > 
> > > Mainly the problem is that other people are still free to use them, 
> > > including the people who write the standard libraries. So you end up 
> > > with weird (and IMO bad) cases like using [] for dictionary lookups and 
> > > << and >> for file IO
> > 
> > I agree with you on << and >>.
> > 
> > But what on earth is wrong with using [] for dictionary lookups?  The 
> > built in arrays are after all just a hack optimization for the case 
> > where the lookup key is known in advance to be a small integer.
> 
> What happens when I use [] with a key that doesn't exist in my 
> dictionary?  Does it return NULL?  Does it create that key with a 
> default value?  Does it raise an exception?
> 
> It's possible to declare that it'll behave in a certain way, of course, 
> but that'll be different from how it behaves in other languages that 
> provide the same overloaded construct, and it'll be different from using 
> [] as the array index operator.

Throwing an exception would seem to be the appropriate thing to do fi 
you use [] as an r-value with an unknown key.  That's consistent with 
throwing an exception when you try to access a vector or string with an 
out of bounds index.

As an l-value, of course, it's perfectly OK to use an unknown key.

Getting both behaviours in C++ requires that [] return some sort of 
smart pointer thingy, so it should be the operator myType() method that 
throws the exception on unknown key, not the [] itself.

It's all a lot easier in Dylan, where the parser recognises x[i] := exp 
as syntactic sugar for element-setter(exp, x, i).  In the same way the 
parser recognises x[i] as syntactic sugar for element(x, i).  The 
"element" function has an optional "default" argument, in case the key 
is unknown or out of bounds.  You don't get access to that when you use 
[].

http://www.gwydiondylan.org/books/drm/drm_102.html#HEADING102-96
http://www.gwydiondylan.org/books/drm/drm_102.html#HEADING102-113

-- Bruce
0
Bruce
11/20/2003 9:16:58 AM
In article <BBE1BCE8.1609E%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> Well I never said it was, it's for UI only. I said it was feasible, and that
> if Apple invested enough resources, they could very well come up with a
> subset with enough consistency to compete with Carbon, thus providing an
> easy move to Carbon developers. And the nice thing about it is that since
> Cocoa windows support Carbon controls, the developers could do it at their
> pace.

But then we come back to the problem of, why is it a better use of 
resources for Apple to start over from scratch, instead of continuing 
their work on Carbon? It seems to me that if they put the same amount of 
work into simply improving Carbon that they'll have a better API than if 
they have to completely start over and make a C API layer on top of 
Cocoa.

> I understand your point about messaging and introspection. I've used
> introspection in Java and I find it very powerful and useful. But how many
> apps really need this language feature ? Don't kill me if I say that in the
> apps that don't, from a programmer's standpoint, writing
> MyObj->DoSomething() (in C++), MyObj.DoSomething() (in Java) and [MyObj
> doSomething] (in Obj-C) are exactly the same, even though the underlying
> concepts are different. It's more a runtime issue than a programming issue,
> don't you think ?

If you use ObjC to write C++-style code, of course you don't need the 
features that ObjC gives you, and you might as well just use C++. A 
determined C++ programmer can write C++ in any language. But if you 
really write in ObjC, instead of using ObjC as if it were a smaller, 
less interesting version of C++, then it's not just a runtime issue. 
Just to toss out one example; how would you implement NSUndoManager, or 
any kind of multiple undo feature, in C++? It typically is extremely 
difficult and involves an incredible amount of extra code, whereas 
ObjC's introspection features make this pretty easy. 

> > But what you're proposing isn't a subset of Cocoa, it's a completely
> > different API. Or are you proposing that they write the program with the
> > C APIs first, then gradually move pieces over to ObjC?
> 
> Yes, exactly, that's what I'm proposing. It's a different API, but it relies
> on Cocoa, so Cocoa is there. All it does is things like the following:
> 
> struct  XCallbacks;
> 
> NSControlRef CocoaCreateButton(XCallbacks* inCallbacks,long inType,long
> inStyle)
> {
>     NSRect rect = { { 0, 0 }, { 0, 0 } };
>     // XCocoaButton is a NSButton with callbacks, and its own target
>     XCocoaButton* ref = [[XCocoaButton alloc] initWithFrame:rect];
>     [ref setCallbacks:inCallbacks];
>     [ref setButtonType:(NSButtonType)inType];
>     [ref setBezelStyle:(NSBezelStyle)inStyle];
>     // send events to controlActioned method, which calls the C callback
>     [ref setTarget:ref];
>     [ref setAction:@selector(controlActioned:)];
>     return ref;
> }
> 
> With this kind of API, it becomes very easy for a Windows or a Carbon
> programmer to call this method, rather than CreatePushButtonControl (in
> Carbon) or CreateWindowEx (in Win32).
> 
> Now imagine that the above code was provided as open-source for all existing
> Cocoa UI objects. Don't you think many Carbon developers would easily switch
> to Cocoa ? Don't you think that, being able to trace that code, including
> the callbacks, they'd get a step by step understanding on what's really
> going on out there ?

I think the existance of such a thing might convince a very few 
developers to investigate Cocoa, but not many. Of those who do 
investigate, even fewer will actually get it. Just one problem that 
immediately occurs to me; your function doesn't follow proper Cocoa 
memory management. Memory management is typically one of the harder 
points of learning Cocoa; how will Carbon developers properly learn 
retain/release semantics if their example code doesn't follow it? Your 
function should be autoreleasing 'ref' before returning it. Of course, 
you can't really do that when you're handing it back to code that's 
clueless about reference counting, so this is certainly not a fault in 
your code, but people who see this code will probably learn the wrong 
thing about how to manage memory with Cocoa.

Basically, there are three groups of Carbon programmers. One group is 
very open, and has already investigated Cocoa and has either switched to 
it, added it to their list of options, or decided it wasn't what they 
wanted. One group is completely closed and will never look at it because 
it's not what they know. And one group is mostly closed but might take a 
look at it if they didn't have to learn that horrible, difficult 
Objective-C. I personally believe that last group is very small, 
although I don't really have any way to back that up.

> > Let's see, [sender tag], that's eleven characters. That seems close
> > enough to "you receive the tag in your event handler" to me. Of course,
> > you still have to hook things up, if that's what you're talking about.
> 
> Yes, and to 'hook things up', you need a class to be the delegate and/or the
> target, and set the action for it. That's significantly more than 11
> characters, and you end up doing this for every single UI object in Cocoa,
> because Obj-C won't support multiple inheritance.
> 
> Currently, if a control or menuitem has no associated action, nothing
> happens, the message is lost. Cocoa could very well provide a mechanism like
> the following:
> 
>  -(bool)actionTriggered:(id)anObject tag:(int)aTag;
> 
> that would by default forward the message to the superview, the first
> responder or the app delegate. That method would be called whenever the
> control or the menu item has no associated action.

@interface DefaultActionNSControl : NSControl {} @end
@implementation DefaultActionNSControl
- initWithFrame:(NSRect)frame { self = [super initWithFrame:frame]; 
[self setAction:@selector(actionTriggered:)]; return self; }
+ (void)load { [self poseAsClass:[NSControl class]]; }
@end

(This is, of course, completely untested code.)

There you go, this does almost exactly what you said, if you put this 
into your app. The difference is that you have to 'manually' get the tag 
with [sender tag] inside actionTriggered:. Cocoa conveniently sends 
actions to the first responder if there is no target set.

Having never used such an approach in a program, I don't really know if 
this is workable. Why doesn't such a solution work for you?

> Advanced UI objects, preemptive threads, that's more than slightly better,
> don't you think ? Yes, if they'd been available in Carbon, I wouldn't have
> switched to Cocoa, but after weeks of fighting with bogus HIScrollViews,
> bogus Textension (yes, i know it's solved in 10.3), and bogus MPRemoteCall,
> I thought I'd better spend my energy in a much more stable environment. And
> I'm very glad I did. Cocoa is indeed much better than Carbon, and Quartz
> better than Quickdraw. But Cocoa requires more work in my case. If I had no
> code to reuse, and no portability issue, maybe I'd write it completely in
> Obj-C using Cocoa classes, but the thing is, I have 3 MB of library code
> written in C and C++, and portability *is* a main concern.

Advanced UI objects can be added to Carbon much easier than writing a 
completely new API layer. Preemptive threads already exist in Carbon, so 
I'm not sure what you're talking about there. (And if you had trouble 
with MP calls, just use pthread calls.) I certainly won't dispute that 
Cocoa is a better programming environment, and that it produces better 
programs, but it doesn't seem to me that a lobotomized C-accessible 
Cocoa is significantly better than straight Carbon. There's nothing 
fundamentally broken with Carbon that makes it unable to have what you 
want, it's just that Apple hasn't gotten there yet.

> > Well, when you write Carbon apps, you're forced to do things the Carbon
> > way, and I'm sure Win32 forces you into the Win32 way.
> 
> Yes, you're right. But since they're very close, and both available in C,
> it's not a big deal. The thing is, the Win32 event model has been up for 15
> years, like many other system APIs. So probably 99% of the graphical apps
> around follow this model. I'm not saying it's better. It's just part of
> history.

The Cocoa model has been around for nearly 15 years as well (I'm sure 
someone will tell me the actual number). For apps that follow the 
Carbon/Win32 event model, Apple has an API that follows that. For apps 
that can handle a change of event model, Apple provides Cocoa.

> Well you see, we have very different standpoints. Windows portability is a
> major concern for me. And I'm pretty sure I'm not the only guy around having
> to deal with that issue, since my customers can't afford paying twice the
> development. Maybe that's why I think many programmers share my ideas on
> Cocoa adoption - extrapolating again.

I don't doubt that many people care about Windows portability, and I 
don't by any means think that it's not a worthy concern, it's just not 
something I personally deal with. Mainly, I just don't see why you don't 
talk about getting Carbon up to snuff, instead of completely redoing 
Cocoa.
0
Michael
11/20/2003 9:22:18 AM
In article <BBE1E60B.160EB%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> That was not possible, because NSTableHeaderView  needs a NSTableView.

Does it actually assert that its superview is an instance of 
NSTableView, or something like that? Not that this would surprise me.

> However it gave me the idea to use NSTableHeaderCell. Was pretty tough since
> there is no NSTableHeader control, however by subclassing NSButton and
> NSButtonCell, and calling NSTableHeaderCell's draw methods instead
> NSButtonCell's draw methods, I got it working. Found very strange things
> such as:
>  - NSTableHeaderCell won't draw properly if the control is not flipped
>  - NSTableHeaderCell won't hilite when its state is on, so you need to call
> highlight instead of drawWithFrame
>  - stopTracking is never called at the end of a tracking session

I think quite a few of these 'embedded' classes are not really meant to 
be used independently, which is too bad. I'm glad you got it working, at 
least.
0
Michael
11/20/2003 9:24:10 AM
dans l'article mail-C6D9AF.10221820112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 20/11/03 10:22�:

>> Well I never said it was, it's for UI only. I said it was feasible, and that
>> if Apple invested enough resources, they could very well come up with a
>> subset with enough consistency to compete with Carbon, thus providing an
>> easy move to Carbon developers. And the nice thing about it is that since
>> Cocoa windows support Carbon controls, the developers could do it at their
>> pace.
> 
> But then we come back to the problem of, why is it a better use of
> resources for Apple to start over from scratch, instead of continuing
> their work on Carbon? It seems to me that if they put the same amount of
> work into simply improving Carbon that they'll have a better API than if
> they have to completely start over and make a C API layer on top of
> Cocoa.

It's a better use, because in the end, they'd be able able to drop Carbon.

>> I understand your point about messaging and introspection. I've used
>> introspection in Java and I find it very powerful and useful. But how many
>> apps really need this language feature ? Don't kill me if I say that in the
>> apps that don't, from a programmer's standpoint, writing
>> MyObj->DoSomething() (in C++), MyObj.DoSomething() (in Java) and [MyObj
>> doSomething] (in Obj-C) are exactly the same, even though the underlying
>> concepts are different. It's more a runtime issue than a programming issue,
>> don't you think ?
> 
> If you use ObjC to write C++-style code, of course you don't need the
> features that ObjC gives you, and you might as well just use C++. A
> determined C++ programmer can write C++ in any language. But if you
> really write in ObjC, instead of using ObjC as if it were a smaller,
> less interesting version of C++, then it's not just a runtime issue.
> Just to toss out one example; how would you implement NSUndoManager, or
> any kind of multiple undo feature, in C++? It typically is extremely
> difficult and involves an incredible amount of extra code, whereas
> ObjC's introspection features make this pretty easy.

Well I'll tell you when it's done...

>>> But what you're proposing isn't a subset of Cocoa, it's a completely
>>> different API. Or are you proposing that they write the program with the
>>> C APIs first, then gradually move pieces over to ObjC?
>> 
>> Yes, exactly, that's what I'm proposing. It's a different API, but it relies
>> on Cocoa, so Cocoa is there. All it does is things like the following:
>> 
>> struct  XCallbacks;
>> 
>> NSControlRef CocoaCreateButton(XCallbacks* inCallbacks,long inType,long
>> inStyle)
>> {
>>     NSRect rect = { { 0, 0 }, { 0, 0 } };
>>     // XCocoaButton is a NSButton with callbacks, and its own target
>>     XCocoaButton* ref = [[XCocoaButton alloc] initWithFrame:rect];
>>     [ref setCallbacks:inCallbacks];
>>     [ref setButtonType:(NSButtonType)inType];
>>     [ref setBezelStyle:(NSBezelStyle)inStyle];
>>     // send events to controlActioned method, which calls the C callback
>>     [ref setTarget:ref];
>>     [ref setAction:@selector(controlActioned:)];
>>     return ref;
>> }
>> 
>> With this kind of API, it becomes very easy for a Windows or a Carbon
>> programmer to call this method, rather than CreatePushButtonControl (in
>> Carbon) or CreateWindowEx (in Win32).
>> 
>> Now imagine that the above code was provided as open-source for all existing
>> Cocoa UI objects. Don't you think many Carbon developers would easily switch
>> to Cocoa ? Don't you think that, being able to trace that code, including
>> the callbacks, they'd get a step by step understanding on what's really
>> going on out there ?
> 
> I think the existance of such a thing might convince a very few
> developers to investigate Cocoa, but not many. Of those who do
> investigate, even fewer will actually get it.

Well Michael, now *you* are extrapolating. What makes you think there are
only a few ? 

> Just one problem that immediately occurs to me; your function doesn't
> follow proper Cocoa  memory management.
> Memory management is typically one of the harder
> points of learning Cocoa; how will Carbon developers properly learn
> retain/release semantics if their example code doesn't follow it? Your
> function should be autoreleasing 'ref' before returning it. Of course,
> you can't really do that when you're handing it back to code that's
> clueless about reference counting, so this is certainly not a fault in
> your code, but people who see this code will probably learn the wrong
> thing about how to manage memory with Cocoa.

That's just a piece of code. The ref is released in another piece of code.
If I release it there, the control is destroyed, since it's not in a
superview yet.

> Basically, there are three groups of Carbon programmers. One group is
> very open, and has already investigated Cocoa and has either switched to
> it, added it to their list of options, or decided it wasn't what they
> wanted. One group is completely closed and will never look at it because
> it's not what they know. And one group is mostly closed but might take a
> look at it if they didn't have to learn that horrible, difficult
> Objective-C. I personally believe that last group is very small,
> although I don't really have any way to back that up.

Well Michael, now *you* are extrapolating. What makes you think there are
only a few ? 

>>> Let's see, [sender tag], that's eleven characters. That seems close
>>> enough to "you receive the tag in your event handler" to me. Of course,
>>> you still have to hook things up, if that's what you're talking about.
>> 
>> Yes, and to 'hook things up', you need a class to be the delegate and/or the
>> target, and set the action for it. That's significantly more than 11
>> characters, and you end up doing this for every single UI object in Cocoa,
>> because Obj-C won't support multiple inheritance.
>> 
>> Currently, if a control or menuitem has no associated action, nothing
>> happens, the message is lost. Cocoa could very well provide a mechanism like
>> the following:
>> 
>>  -(bool)actionTriggered:(id)anObject tag:(int)aTag;
>> 
>> that would by default forward the message to the superview, the first
>> responder or the app delegate. That method would be called whenever the
>> control or the menu item has no associated action.
> 
> @interface DefaultActionNSControl : NSControl {} @end
> @implementation DefaultActionNSControl
> - initWithFrame:(NSRect)frame { self = [super initWithFrame:frame];
> [self setAction:@selector(actionTriggered:)]; return self; }
> + (void)load { [self poseAsClass:[NSControl class]]; }
> @end
> 
> (This is, of course, completely untested code.)
> 
> There you go, this does almost exactly what you said, if you put this
> into your app. The difference is that you have to 'manually' get the tag
> with [sender tag] inside actionTriggered:. Cocoa conveniently sends
> actions to the first responder if there is no target set.
> 
> Having never used such an approach in a program, I don't really know if
> this is workable. Why doesn't such a solution work for you?

Well, thanks for the poseAsClass. Obviously you don't expect a newcomer to
learn how to do this kind of things in a few hours, do you ? That's
definitely a concept that is not available in C++ or Java. So there *is* a
lot to learn with Obj-C, not just the syntax.

>> Advanced UI objects, preemptive threads, that's more than slightly better,
>> don't you think ? Yes, if they'd been available in Carbon, I wouldn't have
>> switched to Cocoa, but after weeks of fighting with bogus HIScrollViews,
>> bogus Textension (yes, i know it's solved in 10.3), and bogus MPRemoteCall,
>> I thought I'd better spend my energy in a much more stable environment. And
>> I'm very glad I did. Cocoa is indeed much better than Carbon, and Quartz
>> better than Quickdraw. But Cocoa requires more work in my case. If I had no
>> code to reuse, and no portability issue, maybe I'd write it completely in
>> Obj-C using Cocoa classes, but the thing is, I have 3 MB of library code
>> written in C and C++, and portability *is* a main concern.
> 
> Advanced UI objects can be added to Carbon much easier than writing a
> completely new API layer.

I don't think so.

> Preemptive threads already exist in Carbon, so
> I'm not sure what you're talking about there. (And if you had trouble
> with MP calls, just use pthread calls.)

Well the problem is you can't even call InvalRect from a preemptive thread.

> I certainly won't dispute that
> Cocoa is a better programming environment, and that it produces better
> programs, but it doesn't seem to me that a lobotomized C-accessible
> Cocoa is significantly better than straight Carbon. There's nothing
> fundamentally broken with Carbon that makes it unable to have what you
> want, it's just that Apple hasn't gotten there yet.

Well rather than asking them to get there, I'd rather ask them to help us go
where what we want is already available. What we want is nice Cocoa
look-and-feel apps, whatever the programming langage is.

>>> Well, when you write Carbon apps, you're forced to do things the Carbon
>>> way, and I'm sure Win32 forces you into the Win32 way.
>> 
>> Yes, you're right. But since they're very close, and both available in C,
>> it's not a big deal. The thing is, the Win32 event model has been up for 15
>> years, like many other system APIs. So probably 99% of the graphical apps
>> around follow this model. I'm not saying it's better. It's just part of
>> history.
> 
> The Cocoa model has been around for nearly 15 years as well (I'm sure
> someone will tell me the actual number). For apps that follow the
> Carbon/Win32 event model, Apple has an API that follows that. For apps
> that can handle a change of event model, Apple provides Cocoa.

And how many apps use the Cocoa model ? This is an economical and practical
concern, not a technical one.

>> Well you see, we have very different standpoints. Windows portability is a
>> major concern for me. And I'm pretty sure I'm not the only guy around having
>> to deal with that issue, since my customers can't afford paying twice the
>> development. Maybe that's why I think many programmers share my ideas on
>> Cocoa adoption - extrapolating again.
> 
> I don't doubt that many people care about Windows portability, and I
> don't by any means think that it's not a worthy concern, it's just not
> something I personally deal with. Mainly, I just don't see why you don't
> talk about getting Carbon up to snuff, instead of completely redoing
> Cocoa.

I'm 100% convinced that what I'm talking about doesn't require to rewrite a
single line of Cocoa code.

A few years ago, there was a rumour saying Cocoa would be the only native
API for OSX. Many companies complained, so Apple said they would provide
Carbon, and they did. Why did they wait until 10.3 to provide a decent text
control ? Why are they still not providing a thread-safe UI layer for Carbon
? IMHO, Apple was hoping developers would move to Cocoa much faster. And it
hasn't happened. So now they're forced to provide a better Carbon. What a
waste of time and resources for everybody. So my message is simple: freeze
Carbon, and help developers move to Cocoa.

Eric

0
Eric
11/20/2003 1:37:23 PM
dans l'article mail-756870.10241020112003@localhost, Michael Ash �
mail@mikeash.com a �crit le 20/11/03 10:24�:

> In article <BBE1E60B.160EB%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> That was not possible, because NSTableHeaderView  needs a NSTableView.
> 
> Does it actually assert that its superview is an instance of
> NSTableView, or something like that? Not that this would surprise me.

I don't know, but I couldn't get it to work. I think it's a single view for
all the columns, and it takes the column widths from the NSTableView.

>> However it gave me the idea to use NSTableHeaderCell. Was pretty tough since
>> there is no NSTableHeader control, however by subclassing NSButton and
>> NSButtonCell, and calling NSTableHeaderCell's draw methods instead
>> NSButtonCell's draw methods, I got it working. Found very strange things
>> such as:
>>  - NSTableHeaderCell won't draw properly if the control is not flipped
>>  - NSTableHeaderCell won't hilite when its state is on, so you need to call
>> highlight instead of drawWithFrame
>>  - stopTracking is never called at the end of a tracking session
> 
> I think quite a few of these 'embedded' classes are not really meant to
> be used independently, which is too bad. I'm glad you got it working, at
> least.

Well my dream was a NSDrawCell, or something of the kind, with proper
parameters. There are plenty of NSDrawSomething, why not this one ?

Eric

0
Eric
11/20/2003 1:44:15 PM
In article <mail-C6D9AF.10221820112003@localhost>,
 Michael Ash <mail@mikeash.com> wrote:

> In article <BBE1BCE8.1609E%eric.vergnaud@wanadoo.fr>,
>  Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
> > Well I never said it was, it's for UI only. I said it was feasible, and that
> > if Apple invested enough resources, they could very well come up with a
> > subset with enough consistency to compete with Carbon, thus providing an
> > easy move to Carbon developers. And the nice thing about it is that since
> > Cocoa windows support Carbon controls, the developers could do it at their
> > pace.
> 
> But then we come back to the problem of, why is it a better use of 
> resources for Apple to start over from scratch, instead of continuing 
> their work on Carbon? It seems to me that if they put the same amount of 
> work into simply improving Carbon that they'll have a better API than if 
> they have to completely start over and make a C API layer on top of 
> Cocoa.
> 

Well, technically, there already is a C API for Cocoa - but it isn't on 
top of it, it is underneath it.

The entire run time can be accessed from C - it makes things look really 
ugly, but it can be done.

Look in /usr/include/objc - you can just call objc_msgSend() directly, 
etc.  Of course, instead of:

   foo = [[Foo alloc] init];
   [foo doSomething:bar];

you'd write:

   foo = objc_msgSend(objc_msgSend(objc_getClass("Foo"), 
SELUID("alloc")), SELUID("init"));
   objc_msgSend(foo, SELUID("doSomething:"), bar);

It's ugly, but it is purely in C - tada!  A C API for Cocoa...
0
Glenn
11/20/2003 3:44:25 PM
In article <BBE28223.16139%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> > I think the existance of such a thing might convince a very few
> > developers to investigate Cocoa, but not many. Of those who do
> > investigate, even fewer will actually get it.
> 
> Well Michael, now *you* are extrapolating. What makes you think there are
> only a few ? 

Mainly because Cocoa has been available to Mac developers in one form or 
another for four or five years. I think that nearly everybody who is 
going to try it already has. But I freely admit that this is speculation.

> > Just one problem that immediately occurs to me; your function doesn't
> > follow proper Cocoa  memory management.
> > Memory management is typically one of the harder
> > points of learning Cocoa; how will Carbon developers properly learn
> > retain/release semantics if their example code doesn't follow it? Your
> > function should be autoreleasing 'ref' before returning it. Of course,
> > you can't really do that when you're handing it back to code that's
> > clueless about reference counting, so this is certainly not a fault in
> > your code, but people who see this code will probably learn the wrong
> > thing about how to manage memory with Cocoa.
> 
> That's just a piece of code. The ref is released in another piece of code.
> If I release it there, the control is destroyed, since it's not in a
> superview yet.

I didn't claim that your code leaks, and I don't believe it does. 
However, it's it's still bad Cocoa memory management. Cocoa memory 
management is comprehensible because of the rules that go on top of the 
refcount system. Rules like, the number of alloc/copy/retain should 
equal the number of release/autorelease within any given pair of {}'s. 
These rules are broken in certain cases, often in -init... and -dealloc 
methods, but through anal-retentive use of accessors, it can be followed 
even there.

I don't know if it would actually work with your framework's 
architecture, but what your code should be doing, in a Cocoa context, is 
returning an autoreleased object.

> > @interface DefaultActionNSControl : NSControl {} @end
> > @implementation DefaultActionNSControl
> > - initWithFrame:(NSRect)frame { self = [super initWithFrame:frame];
> > [self setAction:@selector(actionTriggered:)]; return self; }
> > + (void)load { [self poseAsClass:[NSControl class]]; }
> > @end
> > 
> > (This is, of course, completely untested code.)
> > 
> > There you go, this does almost exactly what you said, if you put this
> > into your app. The difference is that you have to 'manually' get the tag
> > with [sender tag] inside actionTriggered:. Cocoa conveniently sends
> > actions to the first responder if there is no target set.
> > 
> > Having never used such an approach in a program, I don't really know if
> > this is workable. Why doesn't such a solution work for you?
> 
> Well, thanks for the poseAsClass. Obviously you don't expect a newcomer to
> learn how to do this kind of things in a few hours, do you ? That's
> definitely a concept that is not available in C++ or Java. So there *is* a
> lot to learn with Obj-C, not just the syntax.

There isn't "a lot" to learn, there's simply "more" to learn than the 
syntax. Everything you could want to know about ObjC, stuff like posing 
included, can fit in the margins of the ISO or ANSI or whatever C++ 
standard.

Imagine, it's a completely different language which has concepts not 
available in the languages you already know! What a concept! I'm sorry 
to be sarcastic, but I just get tired of hearing this all the time. 
People say, "X is hard in ObjC/Cocoa". I say "No it's not, look, here's 
how you do it". They say "That's totally different from how you do it in 
C++, ObjC is hard." ObjC is *not* C++, and you will run into trouble if 
you treat it as C++ with funny syntax.

I don't expect a newcomer to learn about poseAsClass: and how it works 
in a few hours. I do, however, expect that someone who has spent as much 
time struggling/working with the language as you have to have spent 
enough time reading the documentation to run across this and see how it 
works. Or, barring that, I at least expect someone with some experience 
who says "How can I globally modify the behavior of some class?" will 
actually look in the documentation to see if there's a way to do it, 
instead of assuming that since it doesn't exist in Java or C++, it 
doesn't exist in ObjC.

> > Advanced UI objects can be added to Carbon much easier than writing a
> > completely new API layer.
> 
> I don't think so.

Well, then we just disagree on this. Carbon is reasonably modern. Adding 
new objects to it can't be that hard.

> > I certainly won't dispute that
> > Cocoa is a better programming environment, and that it produces better
> > programs, but it doesn't seem to me that a lobotomized C-accessible
> > Cocoa is significantly better than straight Carbon. There's nothing
> > fundamentally broken with Carbon that makes it unable to have what you
> > want, it's just that Apple hasn't gotten there yet.
> 
> Well rather than asking them to get there, I'd rather ask them to help us go
> where what we want is already available. What we want is nice Cocoa
> look-and-feel apps, whatever the programming langage is.

I would have thought that what "we" want is nice Mac OS X look-and-feel 
apps, whatever the programming language and API. And even if Carbon 
doesn't match your expectations now, there's no reason to assume that it 
never can. The API doesn't matter, it's the result that matters.

> > The Cocoa model has been around for nearly 15 years as well (I'm sure
> > someone will tell me the actual number). For apps that follow the
> > Carbon/Win32 event model, Apple has an API that follows that. For apps
> > that can handle a change of event model, Apple provides Cocoa.
> 
> And how many apps use the Cocoa model ? This is an economical and practical
> concern, not a technical one.

I'm not at all trying to say that it's not a concern, just that age does 
not beget legitimacy, and that there is an API with the event model you 
want that already exists.

> > I don't doubt that many people care about Windows portability, and I
> > don't by any means think that it's not a worthy concern, it's just not
> > something I personally deal with. Mainly, I just don't see why you don't
> > talk about getting Carbon up to snuff, instead of completely redoing
> > Cocoa.
> 
> I'm 100% convinced that what I'm talking about doesn't require to rewrite a
> single line of Cocoa code.

I don't doubt that. When I say "redoing", I mean more like 
re-implementing. Wrapping every single capability that Cocoa offers in C 
would be enormous, and you still couldn't do it all.

> A few years ago, there was a rumour saying Cocoa would be the only native
> API for OSX. Many companies complained, so Apple said they would provide
> Carbon, and they did. Why did they wait until 10.3 to provide a decent text
> control ? Why are they still not providing a thread-safe UI layer for Carbon
> ? IMHO, Apple was hoping developers would move to Cocoa much faster. And it
> hasn't happened. So now they're forced to provide a better Carbon. What a
> waste of time and resources for everybody. So my message is simple: freeze
> Carbon, and help developers move to Cocoa.

I still don't understand how supporting Carbon is a waste of time and 
resources whereas supporting Unnamed-C-Wrapper-For-Cocoa is not. Cocoa 
already uses a ton of Carbon objects internally. The two APIs converge 
more and more as time goes on. Why does Apple make the choices they 
make? I have no idea.
0
Michael
11/20/2003 5:16:07 PM
In article <BBE28223.16139%eric.vergnaud@wanadoo.fr>,
 Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

> dans l'article mail-C6D9AF.10221820112003@localhost, Michael Ash �
> mail@mikeash.com a �crit le 20/11/03 10:22�:
> 
> > But then we come back to the problem of, why is it a better use of
> > resources for Apple to start over from scratch, instead of continuing
> > their work on Carbon? It seems to me that if they put the same amount of
> > work into simply improving Carbon that they'll have a better API than if
> > they have to completely start over and make a C API layer on top of
> > Cocoa.
> 
> It's a better use, because in the end, they'd be able able to drop Carbon.

Carbon can never be dropped until Microsoft, Adobe, and all other 
Carbon-using developers rewrite their applications from scratch.  That's 
never going to happen, so Carbon's with us to stay.  I'm glad it's a 
well-designed framework, since it'd be a shame to be tied to one that 
wasn't. :)

> > Preemptive threads already exist in Carbon, so
> > I'm not sure what you're talking about there. (And if you had trouble
> > with MP calls, just use pthread calls.)
> 
> Well the problem is you can't even call InvalRect from a preemptive thread.

Sure, but you can post an event to your main thread that invalidates 
that rect.  And you can write the 10-line wrapper for that once and then 
call it whenever you want.

> Why are they still not providing a thread-safe UI layer for Carbon?

Because demand for it is very low, the engineering effort to 
retroactively make Carbon and everything it depends on thread-safe would 
be huge, and performance would suffer.  I've never run into a case with 
Carbon development where posting to the main thread wasn't an acceptable 
solution.  Rearchitecting much of the OS to save a few developers a few 
lines of easy-to-write code generally isn't worth it.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://rescomp.stanford.edu/~ejalbert/
0
Eric
11/20/2003 5:53:24 PM
In article <f7e883a5.0311181120.4acdeb26@posting.google.com>,
google@whooley.utvinternet.com (Mike Whooley) wrote:

>I don't know what 'the' correction solution is, but MI is an effective
>method of code reuse with minimal effort. To use an example from
>PowerPlant, the LPeriodical class, an abstract class providing support
>for repeating actions. To add this functionality to one's class, you
>merely add LPeriodical as a superclass, and override one method to
>accomplish the task desired.
>
>Why is this so ugly a feature it has no place in ObjC?

Erm ... you can do this in Objective-C.  In fact Cocoa
implements them as protocols, and provides an NSTimer to
do the triggering for you.

>> It's a named resource!  Your 
>> "better" solution using an open panel *would* have been using a hard 
>> coded file you complain about here!  
>
>Using my method, the icon could be changed in IB without requiring a
>(lengthy) code rebuild simply by selecting a different file. Using
>yours, I would need to rebuild the relevant code if I merely wished to
>change one icon! (Unless, I used a plist setting to specify which icon
>to use - which would be a good example of using a sledgehammer to swat
>a fly. All I wanted to do was set one button icon!)

Using Cocoa you can define two button icons for one button
and tell it when to switch between them without writing any
code at all.  You can do the entire definition in Interface
Builder.

One problem is that you're not used to doing things without
writing code, but then you complain that the ways provided
to write code don't suit you.  The second part may be true
but the first part means that writing code is so rare that
the second part isn't a big drawback.

>but why wouldn't
>C++ be considered an OO language? What does it lack?

It doesn't understand itself.  I can't ask an object what
class of object it is.  I can't ask a class what its super-
classes are.  So, for example, I can't ask for a list of
all bank accounts unless I specifically maintain the list
myself.  I can't ask a bank account what can be done with
it unless I've specifically written code to answer that
question.  I can't ask the system to list all the types of
bank account unless I've specifically written code to
answer that question.  All that functionality comes free
whenever I define a class in Objective-C.

However, I do agree that it's arguable that these are not
features essential to an OO language.  It's just that most
people think they are.


0
slavins
11/21/2003 12:18:26 AM
In article <BBE03D57.15F3B%eric.vergnaud@wanadoo.fr>,
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

>I see no harm and many advantages. Especially when operators allow writing:
>
> String s1 = "message: ", s2 = "Beautiful";
>
> s1 += "Hello " + s2 + " World";
>
>Without operators, this would require 3 lines of code, and be much less
>readable.

Right.  Now consider what happens when someone does this:

 String z1 = "174", z2 = "22";

 [lots of complicated programming here]

 z1 = z1 + z2;

Forgetting that z1 and z2 are strings and not integers.  That's
why overloaded operators are bad.


0
slavins
11/21/2003 12:18:29 AM
dans l'article BBE30A55966871E28@hearsay.demon.co.uk, Simon Slavin �
slavins@hearsay.demon.co.uk@localhost a �crit le 21/11/03 1:18�:

> In article <BBE03D57.15F3B%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
>> I see no harm and many advantages. Especially when operators allow writing:
>> 
>> String s1 = "message: ", s2 = "Beautiful";
>> 
>> s1 += "Hello " + s2 + " World";
>> 
>> Without operators, this would require 3 lines of code, and be much less
>> readable.
> 
> Right.  Now consider what happens when someone does this:
> 
> String z1 = "174", z2 = "22";
> 
> [lots of complicated programming here]
> 
> z1 = z1 + z2;
> 
> Forgetting that z1 and z2 are strings and not integers.  That's
> why overloaded operators are bad.
> 
> 

Not very convincing.

Eric

0
Eric
11/21/2003 3:18:27 AM
In article <BBE30A55966871E28@hearsay.demon.co.uk>,
 slavins@hearsay.demon.co.uk@localhost (Simon Slavin) wrote:

> In article <BBE03D57.15F3B%eric.vergnaud@wanadoo.fr>,
> Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:
> 
> >I see no harm and many advantages. Especially when operators allow writing:
> >
> > String s1 = "message: ", s2 = "Beautiful";
> >
> > s1 += "Hello " + s2 + " World";
> >
> >Without operators, this would require 3 lines of code, and be much less
> >readable.
> 
> Right.  Now consider what happens when someone does this:
> 
>  String z1 = "174", z2 = "22";
> 
>  [lots of complicated programming here]
> 
>  z1 = z1 + z2;
> 
> Forgetting that z1 and z2 are strings and not integers.  That's
> why overloaded operators are bad.

Uh ... no, that's why string literals not being string objects is bad.  
Or why not being able to overload built in operators on built in types 
is bad.  Or why C strings and arrays being silently coerced into 
pointers is bad.

*Luckily*, however, the compiler will not allow you to silently add two 
pointers, so things could be worse...

-- Bruce
0
Bruce
11/21/2003 6:27:48 AM
In article <BBE1BCE8.1609E%eric.vergnaud@wanadoo.fr>,
Eric VERGNAUD <eric.vergnaud@wanadoo.fr> wrote:

>Yes, and to 'hook things up', you need a class to be the delegate and/or the
>target, and set the action for it. That's significantly more than 11
>characters, and you end up doing this for every single UI object in Cocoa,
>because Obj-C won't support multiple inheritance.

No.  Hooking things up is almost never done in code.  It's
done by pointing and clicking in Interface Builder.  So it
takes about five clicks which is even less than 11 characters.
I can think of only one application I've written which needs
to mess with declaring targets and actions in code and that's
one which has to define its own interface depending on the
structure of the data it's given to handle.  This almost never
happens.

People keep insisting on expressing the annoyances of writing
code.  I keep telling them that you don't need to write code.


0
slavins
11/23/2003 11:29:28 PM
In article <mail-C6D9AF.10221820112003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

>But then we come back to the problem of, why is it a better use of 
>resources for Apple to start over from scratch, instead of continuing 
>their work on Carbon? It seems to me that if they put the same amount of 
>work into simply improving Carbon that they'll have a better API than if 
>they have to completely start over and make a C API layer on top of 
>Cocoa.

You may have failed to appreciate the advantages of having an
object-oriented operating system when you're trying to persuade
people to write clean object-oriented code.

If you're trying to persuade people to use sets and iterators,
for example, then using a Cocoa API which hands back the list
of available displays as an array of structs forces the
programmer to do their own conversion or to drop out of OO mind.
Faced with the need to handle arrays and structs, presumably
quickly and elegantly, they'll probably not bother to use OO
techniques in that small part of their code.

Having /everything/ returned as objects, sets or arrays, and
operated as methods helps to keep programmers thinking along
OO lines as they're programming.


0
slavins
11/23/2003 11:29:30 PM
In article <BBE6F35A966812645D@10.0.1.2>,
 slavins@hearsay.demon.co.uk@localhost (Simon Slavin) wrote:

> In article <mail-C6D9AF.10221820112003@localhost>,
> Michael Ash <mail@mikeash.com> wrote:
> 
> >But then we come back to the problem of, why is it a better use of 
> >resources for Apple to start over from scratch, instead of continuing 
> >their work on Carbon? It seems to me that if they put the same amount of 
> >work into simply improving Carbon that they'll have a better API than if 
> >they have to completely start over and make a C API layer on top of 
> >Cocoa.
> 
> You may have failed to appreciate the advantages of having an
> object-oriented operating system when you're trying to persuade
> people to write clean object-oriented code.

Hey Simon, you're right on. I want to reply to Micahel but could not get 
the referenced article.

Michael, what gave you the idea that Apple abandoned Carbon and started 
completely from scratch with Cocoa? Cocoa was around for a long time, 
long before Apple ever even thought about OS X. It wasn't called Cocoa 
of course, it was OpenStep (I believe)...but it was intended for writing 
applications ridiculously fast and also enforcing more uniformity of 
application behavior across the OS. (By making the programmer implement 
only the behavior he wants and leaving the rest to default code in the 
frameworks).

I like cocoa apps a lot. You can definitely tell just by running and 
looking which apps are Carbon and which are Cocoa. Cocoa apps are 
usually faster and prettier, as well as more savvy with OS X technology.

-- 
|\/|  /|  |2  |<
mehaase(at)sas(dot)upenn(dot)edu
0
Mark
11/24/2003 9:16:58 AM
In article <mehaase-2E96FD.04165824112003@netnews.upenn.edu>,
 Mark Haase <mehaase@earthlink.net> wrote:

> Michael, what gave you the idea that Apple abandoned Carbon and started 
> completely from scratch with Cocoa? Cocoa was around for a long time, 
> long before Apple ever even thought about OS X. It wasn't called Cocoa 
> of course, it was OpenStep (I believe)...but it was intended for writing 
> applications ridiculously fast and also enforcing more uniformity of 
> application behavior across the OS. (By making the programmer implement 
> only the behavior he wants and leaving the rest to default code in the 
> frameworks).

I never said anything like what you're saying, that Apple abandoned 
Carbon and started from scratch with Cocoa, so I'm not really sure what 
you're talking about. Of course I know about the history of Cocoa and 
that it's been around for a long time. I did say that Apple *would be* 
starting from scratch on a C API to Cocoa.

> I like cocoa apps a lot. You can definitely tell just by running and 
> looking which apps are Carbon and which are Cocoa. Cocoa apps are 
> usually faster and prettier, as well as more savvy with OS X technology.

This, I can agree with.
0
Michael
11/24/2003 9:43:30 AM
In article <BBE6F35A966812645D@10.0.1.2>,
 slavins@hearsay.demon.co.uk@localhost (Simon Slavin) wrote:

> In article <mail-C6D9AF.10221820112003@localhost>,
> Michael Ash <mail@mikeash.com> wrote:
> 
> >But then we come back to the problem of, why is it a better use of 
> >resources for Apple to start over from scratch, instead of continuing 
> >their work on Carbon? It seems to me that if they put the same amount of 
> >work into simply improving Carbon that they'll have a better API than if 
> >they have to completely start over and make a C API layer on top of 
> >Cocoa.
> 
> You may have failed to appreciate the advantages of having an
> object-oriented operating system when you're trying to persuade
> people to write clean object-oriented code.
> 
> If you're trying to persuade people to use sets and iterators,
> for example, then using a Cocoa API which hands back the list
> of available displays as an array of structs forces the
> programmer to do their own conversion or to drop out of OO mind.
> Faced with the need to handle arrays and structs, presumably
> quickly and elegantly, they'll probably not bother to use OO
> techniques in that small part of their code.
> 
> Having /everything/ returned as objects, sets or arrays, and
> operated as methods helps to keep programmers thinking along
> OO lines as they're programming.

Thus the magic of CoreFoundation. Modern Carbon code does mostly use OO 
objects, sets, and arrays, in the form of CF objects. Apple *is* moving 
towards Cocoa/Carbon convergence. Just look at CF/NS toll-free bridging, 
the ability to mix windows and event handlers in the same app, etc.

Carbon has two goals. One is to be the procedural API, the other is for 
portability. The old really-non-OO methods have to stay around for 
portability reasons. The new OO methods, which do exactly what you're 
saying via CF objects, are quickly becoming the recommended way.

I have never said anything about Carbon being better, or OO techniques 
being worse in a C environment, or anything like that. *All* that I have 
said is that I think it is a bad use of Apple's time to ditch Carbon and 
start over from scratch on a C wrapper API for Cocoa.

Time to convince my news server to post the article as-is, since I don't 
want to snip anything... is this enough?

No.... how about this?
0
Michael
11/24/2003 9:49:45 AM
In article <mail-40923D.10433024112003@localhost>,
 Michael Ash <mail@mikeash.com> wrote:

> I never said anything like what you're saying, that Apple abandoned 
> Carbon and started from scratch with Cocoa, so I'm not really sure what 
> you're talking about. Of course I know about the history of Cocoa and 
> that it's been around for a long time. I did say that Apple *would be* 
> starting from scratch on a C API to Cocoa.

True..I completely misread your post. I was just glancing at the history 
of this thread and there are way too many articles (and not so many on 
my news server) that its futile for me to go back and see who did say 
that, if anybody.

You're right though, a C API for Cocoa is unneccessary.

-- 
|\/|  /|  |2  |<
mehaase(at)sas(dot)upenn(dot)edu
0
Mark
12/1/2003 5:45:58 AM
Reply: