OOP and Foundation 3: Protocols and collections
OOP and Foundation 3: Protocols and collections
- Subject: OOP and Foundation 3: Protocols and collections
- From: Michael Gersten <email@hidden>
- Date: Mon, 10 Jun 2002 13:39:25 -0700
This is part three.
Again, Bill felt that I had some good ideas that were at odds with how Foundation works.
The Readers Digest version:
Point 3:
Inheritance, and protocols, in ObjC are insufficient. You cannot, for example, add the pair of NSCollection and NSMutableCollection without problems. They cannot go as class clusters (informal protocols), but only as real protocols, yet protocols have serious limits that others have written about.
The full details:
>
> Collections are handled HORRIBLY in Foundation. I don't think you can do
>
> it right in ObjC.
Before I say anything else, let me repeat my last line. I don't think you can do collections right in Objective C. Anything you do will be a trade-off of some kind.
>
... stuff about collections deleted. it seemed a non-issue in this
>
context (and incomprehensible, but that may just be me) ...
The idea was that there are some operations common to all collections.
And, there are plenty of cases where any collection is just as good -- as long as you can work with objectEnumerator, and you don't care about the order, any collection is good.
But although I can think of lots of places where an NSArray is taken as an argument, I can't think of any place that takes a generic collection. In fact, there isn't any generic collection protocol or cluster. And, although NSArray may be the only ordered collection in Foundation, that doesn't mean that OrderedCollection, as a generic, isn't usable. I can imagine an ordered dictionary, for example.
[There is a difference between OrderedCollection (such as a B-tree) and IndexedCollection (such as a dictionary. There is also OrderedIndexedCollection, for sorted dictionaries, and NumericalIndexedCollection, for float-addressed arrays, and SequentialNumericalIndexedCollection for NSArray's.]
[Just as an example, EOF has code to deal with arrays, but the truth is, unless you have a sort clause on your fetch spec, the output order (from the DB) is indeterminate, and the input order (to the DB) is (always?) irrelevant. No, not that the order of "Master before details", but the order of this array of details]. [[From what I understand, this is one of the big differences between EOF and a true object DB -- inherent DB support for real ordered arrays.]]
And, this is where I got into the limit of Objective C on collections.
As soon as you want to have some concept of generic collections, you'll also want some concept of generic mutable collections.
But now the class hierarchy becomes undrawable. A concrete example: NSMutableString needs to inherit from both NSString and generic mutable collection.
What you need, in some sense, is properties. You'd need some way to say "This class has the property of being a collection". And to say "I can take any argument that has the property of being a collection".
[This would clean up my previous sample: you'd have a generic collection, and then properties of "Ordered", "Indexed", "Numerical", and "SequentialNumerical". Note that the previous "OrderedIndexed" is now just having two properties.]
Protocols do much of this.
Others have written lots about the problems of protocols.
I haven't looked at how much of the limitations of protocols are based on the current implementation, and how much are inherent.
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
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.