Re: [Tads3] 'inherited' and propNotDefined

[Jesse Welton <jwelton@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Mike Roberts wrote:
> 
> Does anyone see a problem with changing the way 'inherited' is processed so 
> that propNotDefined is fired if there is no inherited definition of the 
> method?

Something like this makes sense, I think, but I'm not sure I
understand where you would actually want to use it.  It's a rather
different situation than regular propNotDefined handling.  In the
propNotDefined case, you're catching in bulk arbitrary calls from
outside.  In the case of propNotInherited, you are catching a very
few, known, internal calls which are specific to your proxy (or
whatever) implementation.  The existence, or not, of an inherited
method is in principle determinable at compile time.  This makes it
hard for me to imagine a real need for this dynamism.  That's not to
say it's a bad idea; I just don't yet see its utility.

Let me try to understand your example:

> class Proxy: object
>   proxyBase = nil
>   propNotDefined(prop, [args]) { return proxyBase.(prop)(args...); }
> ;
> modify Proxy
>   abc(x) { return inherited(x); }  // doesn't work: there's nothing to 
> inherit
>   xyz(x) { return proxyBase.xyz(x); } // works, but breaks if we add xyz() 
> to Proxy
> ;

Part of my problem is that I forget how inherited works with modify.
>From the comments here, I take it that it calls the version from the
unmodified class.

Now, I can see the problem with abc: with the current handling,
inherited fails to tickle the propNotDefined mechanism.  The point
you're making is that the explicit delegation of xyz isn't
satisfactory either.  It fails if xyz is added to Proxy, in the sense
that the modified proxy doesn't call the updated Proxy.xyz behavior.
It seems to me that this just means the modified version needs to be
updated in response to a change in the protocol of the original Proxy.

> One more detail: I think that the propNotDefined (or propNotInherited or 
> whatever) to be invoked would have to be found using the same rules that we 
> use to use to try to find the inherited method that turns out not to exist.  

It seems to me wholly unclear what the correct semantics are here.  In
the abstract, both options seem viable.  Maybe the inherited
propNotInherited gives the correct behavior for the "inherited"
overridden method.  On the other hand, maybe the specialized proxy's
specialized propNotInherited is expected for all propNotInherited
calls.  Without a more concrete example, I don't know how you could
say.

One possibility might be to look up propNotInherited in the
superclass, and to have the default implementation turn around and
call self.propNotDefined, thereby looking it up in the current class.
Thus, by default, you have the same effect as if you simply caught it
with propNotDefined in the current class; but this behavior could be
overridden at the propNotInherited level.  It's an extra lookup, but
it should be rather rare for this mechanism to be invoked.

-Jesse