Roel Wuyts <roel.wuyts at iam.unibe.ch> wrote:
> 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. 
Hmm, right. It's not delaying implementation, but refusing it.

>ShouldNotImplement is used for
> 'cancellation': 'removing' unwanted behavior inherited from superclasses.
> Maybe this is another category.
I think it should be, but it's not so important.

> >>     - extends (overide + call super)
[super calls on different names]
> 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 know - the question is whether this is worth showing. As in the
previous case, I'm not sure what I want to do with the relatively rare
cases.

> I normally call this is a 'bad super send', and
> show it differently from regular super sends.
and
> Yes, it quickly does, does it ? I never found a good intuitive way of doing
> it...
Where do show these sort of things?
Are you implying that SOUL got a body? how is that going?

> > BTW, you have better ideas about how to display these things? I think
> > the single-letter-flag idea is past it's usefulness ;-)
> 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 ?
I was thinking of icons too, but I like the tooltip idea.
The problem with icons is you need pretty icons (a problem by itself ;-)
that designate some pretty abstract ideas...

Daniel