Re: an interesting delegate design issue raised by IB...
Re: an interesting delegate design issue raised by IB...
- Subject: Re: an interesting delegate design issue raised by IB...
- From: Ondra Cada <email@hidden>
- Date: Thu, 13 Sep 2001 11:01:48 +0200
Michael,
>
>>>>> Michael B. Johnson (MBJ) wrote at Wed, 12 Sep 2001 14:45:47 -0700:
MBJ> >Frankly, I can't imagine none such reason just now. My programming
MBJ> >experience just kind of hints that *if* the API would not make that
MBJ> >possible, then some such reason would occur one day ;)
MBJ>
MBJ> *Then* I change the API, not before.
Might cause a slight problem if the developer who happens to encounter the
reason is just some user of your kit, not you personally.
MBJ> If someone can't come up with a compelling real case of why they
MBJ> need something in an API, it shouldn't be in there. Otherwise, it's not
MBJ> clear what is "best practice".
Well, I design my APIs slightly differently, trying to add at least hooks
even for behaviours which I don't see reasonable just now -- the idea is that
some other developer might. Naturally...
MBJ> Just my opinion, of course.
...this is just _MY_ opinion, and might be utterly wrong. And...
MBJ> This is obviously more of a discussion of philosophy now, so perhaps we
MBJ> can just agree to disagree.
...I do absolutely agree with this.
Well, perhaps one slight note: I live under impression that the OpenStep was
(and Cocoa is) designed rather "my" way, ie. being on the flexible side even
if it might bring some potential danger (compare eg. OpenStep
retain-counting to Java GC!). Therefore it might be resonable to try to keep
the design philosophy consistent even for 3rd party kits.
It is quite possible of course it is just my oversight, and you see that
differently.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc