Re: Abstract classes and methods
Re: Abstract classes and methods
- Subject: Re: Abstract classes and methods
- From: "Michael B. Johnson" <email@hidden>
- Date: Wed, 29 Aug 2001 08:28:50 -0700
- Organization: Pixar Animation Studios
Ondra Cada wrote:
>
>
Michael,
>
>
>>>>>> Michael B. Johnson (MBJ) wrote at Tue, 28 Aug 2001 22:40:56 -0700:
>
MBJ> People (and Apple) talk
>
MBJ> about "informal protocols", which means that they implement the methods
>
MBJ> but don't declare the protocol as one that they conform to. I've never
>
MBJ> understood why people do this, but Apple does this a lot...
>
>
'Tis easy -- since you generally want to implement only _some_ methods (even
>
none, sometimes) of the informal protocol.
>
>
Whilst a formal protocol defines methods the class _has to_ implement, an
>
informal one defines methods the class _may_ implement. That's the
>
difference.
right, I understand delegates, but what I'm complaining about is the fact that people have these
different protocols for being a (say) NSOutlineView delegate. These potentially different formal
protocols get lumped into one informal protocol (i.e. if you want to be an aggressive delegate,
implement these 2 methods, if you want to be a lazier one, implement this one method, etc.).
The problem with this, for me, is that invariably I'll screw up the function signature of one of
these delegate methods the first (or more likely second) time I implement it and so my routine never
gets called. Because my subclass is trying to implement an informal protocol to be a delegate as
opposed to a formal one, I get no help from the compiler. If I said:
@interface yabba : NSView <NSOutlineViewLazyDelegate>
the compiler could tell me that I hadn't implemented load:baz:bar:foo:when:needed: (which I had
accidentally implemented as load:bar:baz:foo:when:needed:)
If class designers *used* the language (as far as I know, protocols are part of the language,
informal protocols are not), so that the developer can leverage the *compiler* more, I would be
happier. Maybe these errors never happen to you, but they have happened often enough to me that I
don't understand the reasoning for not taking an informal protocol of some set of methods and
turning that into some reaonable set of formal protocols that I can make my class conform to.
Hope that's clearer.
--> Michael B. Johnson, Ph.D. -- email@hidden
--> Studio Tools, Pixar Animation Studios
-->
http://xenia.media.mit.edu/~wave