Re: Cocoa's Popularity
Re: Cocoa's Popularity
- Subject: Re: Cocoa's Popularity
- From: Michael Gersten <email@hidden>
- Date: Mon, 01 Apr 2002 17:58:44 -0800
OK, I know it's flame bait, but a few points in here need to be addressed.
>
Cocoa
>
and Objective-C are the "right" way to do OOP, if there is such a
>
thing.
Sorry, that's just not the case. There's the old question of "How do you design a hiarchy of rectangle and square?", with the intuitive answer of "Square is a type of rectangle", the programming answer of "No, you can do things to a rectangle that you can't do to a square, so square is the parent -- rectangle permits more, is a subclass". And, the overlooked answer of "Make polygon the parent of both, then right-angled polygon; square and rectangle are siblings".
Collections are handled HORRIBLY in Foundation. I don't think you can do it right in ObjC.
Consider NSString. It's unmutable, right? If you're given an NSString, you know it's unchanging, right?
Wrong. NSString is two things -- One, an API for all strings, a base functionality, and Two, a class that implements that functionality (ignoring class clusters for a moment).
Why is NSMutableString a subclass of NSString? Sure, you can do more with it. But you can't count on an NSString being an NSNonmutableString -- that subclass of NSString was never standardized.
Similarly with NSSet, NSDictionary, etc -- the assumption of "More flexibility means a subclass" ignores the idea of "this class guarantees that you can't do X, use class Y if you want that."
[Some other languages assume that a String is mutable, and you put a nonMutable filter object on it if you want to prohibit alterations. But that just means you'll get runtime errors for class mismatches.]
But now comes the ObjC killer: NSCollection, NSMutableCollection, NSNonmutableCollection. These classes would define things like objectEnumerator, count, etc. NSMutableCollection would have addItem, etc. Maybe NSDictionaryArray or NSDictionarySet would be a collection of NSValuePairs (each pair being a key and a value), optimized as such, with mostly the same API as NSDictionary, but being from NSCollection (so its objectEnumerator would return these pairs, and addItem would take one of these pairs to add.)
An NSString would be a type of NSCollection; an NSMutableString, a type of NSMutableCollection.
In most cases, you'd only need to specify an argument of NSCollection; on rare occasions, NSOrderedCollection. Specifically saying NSArray wouldn't be needed very often. If you replace explicit objectAt loops on NSArray with objectEnumerator loops, most things can take NSSet or NSDictionary just fine.
Now, what's the inheritence chain? NSMutableString wants to be NSString, NSMutableCollection, and NSCollection. NSNonmutableString wants to be NSString, NSNonmutableCollection, and NSCollection.
The second problem of Objective C: Class versus protocol. Unless you know the details of a class's implementation (either public members, or 'friend'-like of C++), you don't take a class object as an argument, you take an object that meets the protocol of that class.
If you didn't understand that: Defining a class should define both a class (which affects code inheritence), and an interface/protocol corresponding to that class; when you declare something as an incoming argument (excluding the ** [outbound argument] case), you say that you want something that fits that protocol, regardless of what class it actually is. Right now ObjC has that only because it doesn't do enough checking (or is lied to) -- nothing under NSProxy inherits from anything under NSObject, but you can give something from NSProxy to a method that wants an NSObject descendant. The code doesn't notice, because the compiled code only uses the inherent protocol. But if the compiler knew what was going on, it would complain; if there was strict type checking, it wouldn't fly.
What does this give you? If you have a new class, relatively unrelated to an existing class, but with one of those old class members as an ivar, you could give a compiler directive to say "Anything I didn't mention of protocol classFooProtocol that is sent to me is forwarded to ivar myFoo". Then, you can have an NSView as an ivar, make sure that it always stays offscreen, never becomes first responder, and use your class exactly as an NSView for drawing, even though you are completely unrelated. Call it "MyOffscreenBitmap", or something like that. Completely unrelated to NSView _codewise_; fully equivalent for drawing into it and giving it to other routines that work with NSView.
>
In the past, I looked into C++, but it's such a, well, it's an
>
ugly language. There are too many changes, too many syntax additions,
>
too much nonsense grafted onto the side of a language that is above all
>
clean and consistent. Objective-C simply adds one new sort of syntax
>
and a few data types. It's graceful.
C++ has one absolute saving grace: operator overloading. Think complex numbers, or matrix mathematics. Something as simple as
root = ((b * b) - (4 * a * c)) / (2 * a)
where a, b, c, and root are objects and need ObjC's message syntax? And that's a real simple example.
Now, C++'s complexity comes from one thing:
root =
What it takes to define the operator=& method for a class is the whole "pointers aren't sufficient -- we need this reference beast" reason for C++. The syntax mess of this and other reference things, yes, it's ugly. Just accept it as the c++ standard class template. (Copy constructor, regular constructor, destructor, assignment, did I miss a required method for a non-trivial class?).
>
Foundation and AppKit classes
>
take the tedium out of coding to a large degree, and I'm free to focus
>
on thinking in higher and freer terms than "this does this then that."
>
I can see my program as objects instead of as a bunch of spaghetti
>
code. Furthermore, I can design, I can be artful, and I can be
>
productive- all at the same time.
Yes. Foundation is a huge gain over what came before it. Appkit is mostly a gain. But they are not the best possible, end-all of programming and GUI API's.
>
(incidentally, I stood, and still do stand, for the no-floppy
>
decision. (: Floppies have been dead for a long, long, long time. Even
>
in the early/mid-90s, I found them quite close to useless... ^_^)
Ok, how do you move files between computers that are not linked by a network cable?
Writable CD drives are now a realistic alternative, for new machines (not for older machines, even today). But they are rarely easy to use; MS windows has a brain dead assumption that certain file systems are only valid on certain devices, so a packet-writing CD-R won't read on a CDRom drive. (Haven't played with this situation on OS10, so I don't know if they did it better).
Yes, floppies have been too small for a real long time. But for a long time, there was no other way to move stuff from machine to machine.
"Get a network". Sorry, some machines aren't in the same room. Some older machines couldn't take a network card. Serial cables? Unreliable.
"Use a temporary internet holding site". Did this, many times. Slow, but it worked. Worked better than floppies for large things.
A Next Cube, with no way to move things (data files) on or off from my Amiga? Yuck. A pizza box, with floppy? Great.
Michael
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.