On 02/06/01 17:27, "danielv at netvision.net.il" <danielv at netvision.net.il>
wrote:

> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
>> What could be interesting to add is:
>>     - abstract methods
> Done. Wasn't sure whether methods that call #shouldNotImplement also
> count as abstract. What do you think?

Well, no, as the intention is not that subclasses should override this to
implement the behavior, quite the contrary. ShouldNotImplement is used for
'cancellation': 'removing' unwanted behavior inherited from superclasses.
Maybe this is another category.
 
>>     - extends (overide + call super)
> It now says SU if the method calls upon super. This raises two issues -
> 1. For the other indications, if you get them you don't need to know the
> methods complexity. Should one get things like SU3 for a complex, super
> calling method? 
> 2. SU isn't exactly like extends, because some methods call super
> differentMethod. Is this an important distinction?

Yes. Methods with a selector foo: that in their implementation call do a
super call to another method then foo: are considered very bad and could
lead to hard-to-track bugs. I normally call this is a 'bad super send', and
show it differently from regular super sends.
 
>>     - override without super call
>>     - delegate 
> define delegate... (same parameters? same name? or just only a single
> send? does it have to return the result of the delegation?)
> 
> BTW, you have better ideas about how to display these things? I think
> the single-letter-flag idea is past it's usefulness ;-)

Yes, it quickly does, does it ? I never found a good intuitive way of doing
it... Icons are also not very practical. Maybe letters or icons in
combinations with tooltips ? That way you can hover over an icon/flag and
get more info ?