Re: OOP and Foundation 3: Protocols and collections
Re: OOP and Foundation 3: Protocols and collections
- Subject: Re: OOP and Foundation 3: Protocols and collections
- From: Michael Gersten <email@hidden>
- Date: Wed, 12 Jun 2002 10:08:39 -0700
This might be our point of disagreement.
To me, static typing is a very good thing: I assert that this object has these valid methods.
I like assertations. I like being able to tell the compiler, "I expect that this object does <foo>".
I don't like the current system of only getting this by class that we have at current.
I like the idea of finer grain control, of being able to say "I want a collection", or "I want access pattern <bar> for this collection".
And, more importantly, I want the apple libraries to be re-declared in terms like this.
Right now, NS collections other than NSArray and NSDictionary are not very well/often used.
Yet the truth is, the DB returns to EOF the equivalent of an NSSet if no ORDER BY clause is on the fetch. EOF converts that NSSet to an NSArray -- why? Answer: Because NSSet isn't usable to most of foundation. Why?
Because Apple's libraries were not declared to take the least restrictive input that they could use. Even though many/most of the calls only need an NSCollection (objectEnumerator), or NSIndexedCollection (something that responds to keyEnumerator), or sometimes an NSOrderedCollection (a meaningful order to objectEnumerator/keyEnumerator), they still take an NSArray, or occasionally NSDictionary.
(I never programmed against indexing kit. I do recall that it had more protocols than classes. I like that.)
Now, taking a second look at what you wrote,
>
On the other hand, I personally *don't think* that "there needs to be some
>
way to indicate to the compiler that...": in my view of dynamic languages
>
like ObjC the invariant is that the class (or, rather, instance) behaviour
>
is *DYNAMIC*, and thus *IN PRINCIPLE* compiler knows plain nothing!
Yes, the class is dynamic. The compiler doesn't know what the class does.
The compiler does know what the user wants to do with the object.
That's why I want to see more things -- arguments and returns -- declared by protocol, not by class.
Yes, there will be times that the object will do what's wanted, and the compiler can't tell.
If you had strict checking, the compiler would complain and abort, even though runtime would succede.
That's the rare case, and the 'id' type.
Ondra Cada wrote:
>
>
On Monday, June 10, 2002, at 11:38 , Michael Gersten wrote:
>
>
> There still needs to be some way to indicate to the compiler (as well as
>
> the "respondsTo:" query) that an NSMutableString implements the string
>
> methods and the mutable collection methods.
>
>
Well... there is (at least I think so), but(!).
>
>
At least theoretically, you can prepare a (quite complicated!) set of
>
protocols, which would describe the behaviours, and use them all. Whenever
>
you find a problem with rigid inheritance, you solve it by splitting
>
protocols to more fine-grained ones. The first approximation would be
>
something like
>
>
@protocol Collection ...
>
@protocol MutableCollection <Collection> ...
>
@protocol String ...
>
@protocol MutableString
>
>
@interface NSString <String, Collection> ...
>
@interface NSMutableString <MutableString, MutableCollection> ...
>
>
Probably you'd need to go more fine-grained, splitting Collection to some
>
BaseCollection and OrderedCollection and hell knows what, and so on. It
>
would be quite inconvenient, but -- unless I missed something? -- very
>
possible.
>
>
On the other hand, I personally *don't think* that "there needs to be some
>
way to indicate to the compiler that...": in my view of dynamic languages
>
like ObjC the invariant is that the class (or, rather, instance) behaviour
>
is *DYNAMIC*, and thus *IN PRINCIPLE* compiler knows plain nothing!
>
>
All right, I do use NSString* instead of id and I do use informal
>
protocols and more, but I consider them just *conveniency tricks*, which
>
in a very good sense go *contrary to* the language principles.
>
---
>
Ondra Hada
>
OCSoftware: email@hidden http://www.ocs.cz
>
private email@hidden http://www.ocs.cz/oc
--
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.