• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Abstract classes and methods
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Abstract classes and methods


  • Subject: Re: Abstract classes and methods
  • From: "Michael B. Johnson" <email@hidden>
  • Date: Wed, 29 Aug 2001 10:40:49 -0700
  • Organization: Pixar Animation Studios

Ondra Cada wrote:
>
> Michael,
>
> >>>>>> Michael B. Johnson (MBJ) wrote at Wed, 29 Aug 2001 08:28:50 -0700:
> MBJ> The problem with this, for me, is that invariably I'll screw up the
> MBJ> function signature of one of these delegate methods the first (or more
> MBJ> likely second) time I implement it and so my routine never gets called.
>
> Well, copy&paste is your friend! I can't remember me once writing, say,
> those NSTableView datasource methods "by hand".

this is silly. You can't, I can. If there are mechanisms in a language that help this stuff, why
not use them? I haven't heard any arguments to convince me that informal protocols have any
advantage over formal ones. Just because a protocol is made formal, doesn't mean that the client
has to conform to it, but by making it formal, the client developer has the *option* of doing so.

I would like this option, and don't understand why other developers (especially Apple) don't package
these informal protocols in formal ones when it make sense.


> Otherwise, though I understand the problem (been bite by it once or twice
> myself) I guess the possible "solution" of having oh-so-many different
> protocols for all possible different usages of informal ones would bring more
> grief than advantage.
>

umm, why? How can this possibly be more grief than advantage?


> Well, if you would like that more than the current solution (I would not,
> for one), DIY! Nothing prevents you from declaring appropriate formal
> protocol in your own headers the first time you use any informal one, and use
> it for all the next times...

umm, I do. My whole point was I don't understand why others don't.

All the other things that you're talking about are policy, which can easily be messed up by people
less disciplined than yourself (me, for example). I'm talking about using the mechanism that the
language provides to help the developer be more efficient...

<shrug>

guess we'll agree to disagree, but it would be nice to hear from others on this.



--> Michael B. Johnson, Ph.D. -- email@hidden
--> Studio Tools, Pixar Animation Studios
--> http://xenia.media.mit.edu/~wave


  • Follow-Ups:
    • Re: Abstract classes and methods
      • From: Carlos Weber <email@hidden>
    • Re: Abstract classes and methods
      • From: Ondra Cada <email@hidden>
References: 
 >Re: Abstract classes and methods (From: "Michael B. Johnson" <email@hidden>)
 >Re: Abstract classes and methods (From: Ondra Cada <email@hidden>)
 >Re: Abstract classes and methods (From: "Michael B. Johnson" <email@hidden>)
 >Re: Abstract classes and methods (From: Ondra Cada <email@hidden>)

  • Prev by Date: Re: Is K&R Still Relevant?
  • Next by Date: Looking for a workaround for a Bug in Cocoa Window
  • Previous by thread: Re: Abstract classes and methods
  • Next by thread: Re: Abstract classes and methods
  • Index(es):
    • Date
    • Thread