Andreas wrote:
> Jecel wrote:
> > Yoshiki Ohshima wrote:
> > >   double-colon in C++.
> > 
> > Very close, ...
> 
> Not at all. It works only if there are no virtual methods involved (which is
> why I mentioned an OOP system). Otherwise it's exactly like 'super' - in
> both cases you're basically creating an anonymous copy of the method in
> question within the receiver. So you are not getting the POV of the class
> you have specified.
> 
> >... and exactly it for his particular examples.
> 
> Seems that my examples haven't been good. Here's a better one:
> 
> 	aDictionary perform: #detect: asSeenBy: Set with: aBlock
> 
> This should - assuming the POV of Set - detect an Association, not a value
> in aDictionary.

Ah! Now I see what you want. Not only do you need that the #detect: message
invoke the Set>>detect: method, but you also want the expression "self do: ..."
inside that method to invoke Set>>do: instead of Dictionary>>do:

Yes, this is very different from a named "super" (double colon in C++ with
virtuals). 

> > In NeoLogo, I often found myself needing to "go the other 
> > way" so I came up with the "as" method. 
> 
> Something like #as: is much closer to what I mean - it's just that it's so
> awkward to use since it's not clear what you really mean by aDictionary as:
> Set - do you want a Set containing the values or the associations?!

If we say that "aDictionary as: Set" gives us as new viewpoint on the same
object, while "aDictionary asSet" gives us the old object *converted* to the
new class, then we can be very clear about what we mean.

To have #as: work as you want (affecting all nested messages to self, perhaps
including indirect ones) maybe it should return a proxy object that would hold
the original receiver and the viewpoint. But since lookup would be affected in
a more complex way than simple redirection can handle, this might require VM
support.

This reminds me of the dashed-line turtle example of the old (1986?) delegation
vs inheritance wars at OOPSLA. How to control how far the new viewpoint should
go? "super" will revert back to the original viewpoint after the first message
send. "as:" will stick to the new viewpoint forever.

I have seen some complex proposals, but perhaps there never will be a good
automatic solution (as opposed to manually creating #detectAsSet: and #doAsSet:
methods in Dictionary). Self 1.0 and 2.0 included a complex multiple
inheritance scheme with:
 
   - "parent priorities": you could control the lookup order

   - "tie breaker rules": when you inherited multiple methods which were
      different but had the same name (Self inherits state, not state definition
      like Squeak so it avoids the problems of multiple variable inheritance)
      there was a complex rule to determine which one to use

   - privacy: slots declared as private were ignored in the lookup except in
      messages to self.

It seemed like a great system on paper, but in practice the methods that got
invoked never were the ones you were expecting when all of these "features" were
used together. So in Self 3.0 parent priorities were eliminated, the tie
breaker rule was killed (now it was always an error to inherit more than one
method with the same name. The programmer has to fix things manually when that
happens) and privacy became just informative (like the "private" method
category in Squeak).

You might have noticed that I prefer to evolve languages by taking things away,
rather than adding them (I had no influence in the Self 2.0->3.0
simplification, but I sure liked it!). I am perfectly willing to add something
if it will eliminate two or more other things. That would have to be the case
for "as:" too.

-- Jecel