Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!bellcore!texbell!sw1e!uucibg From: uucibg@sw1e.UUCP (3929]) Newsgroups: comp.lang.c++ Subject: Re: objective c Message-ID: <1528@sw1e.UUCP> Date: 25 Apr 89 16:26:07 GMT References: <4800061@m.cs.uiuc.edu> <6590106@hplsla.HP.COM> Reply-To: uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) Organization: Southwestern Bell Telephone Co Lines: 75 In article <6590106@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >> I don't understand this at all. Why do you >> claim that ObjC is not OO? Maybe it's slower than C++, >> but that doesn't eliminate it from the realm of object-oriented >> languages. > >To me, a language is still not OO if it "supports" OO but at >such a high cost that real world programmers cannot afford >to use OOP style "all the time." Real world programmers *DOING WHAT*???? What class of problems are you aiming at? >Examples of the kind of code you see people writing if a language >does not support OOP at a reasonable cost include: >* Code that regularly violates the encapsulation of objects by accessing >its instance variables directly rather than thru access functions. You must mean things like friend functions, eh? :-) >* Code that relies heavily on cpp macros to hack at the underlying >implementation of objects. Like all the current hacks in C++ (like the various parameterized types hacks <*not* the proposed approach Stroustrup described> and such)? >* Code that relies heavily on type coercions, with hopeful expectations >of portability across a variety of machines. Could you please explain a bit more? I'm not sure I see what you're getting at here. >* The base language is constantly growing, with new fundamental features >being added to it, as more and more people discover that they cannot >get what they need to get done in a reasonable execution time, based >on the prior rev. of the language's feature set. Like the current rough and tumble which is occuring in the C++ world? Note that there have been few changes to Objective-C. >* Foundation classes that make use of all kinds of hacks to try and >get reasonable speed out of the language -- if the language is not >suitable for the implementors of the language to write in -- then >how can it be suitable for other serious users ??? I can't speak from experience here. But I've seen the source for the foundation classes in Objective-C and they certainly don't appear to be hacks to me (though one man's hack is another man's elegant solution). >* Division of the users of a language into two camps: 1) we, the >full time, professional writers of foundation classes that run >fast, but are indecipherable, [and work only in ideal circumstances] >and 2) you, the user of these foundation classes who are expected >to write half-fast programs based on our fast, hack, foundation >classes -- which may or may not work in your actual usage. Again, please expand upon this. Show me what you mean, give me examples or at least explanations. I'm still evaluating OOP languages, and haven't passed judgement on any of them yet. However, several of your arguments which I assume are directed against Objective-C seem to incrminate C++ instead. Just a final note: I'm not convinced that Objective-C can't be used "all the time" in object-oriented mode. I'll wait to see some real benchmarks on programs which "seem" like they ought to be equally solvable in either language A or language B (in this case Objective-C and C++, though I'd like to see other benchmarks performed). Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 ...!uunet!swbatl!sw1e!uucibg #include