Re: [Tads3] 'inherited' and propNotDefined

["Mike Roberts" <mjr_@xxxxxxxxxxx>]

Jesse Welton <jwelton@pacific.mps.ohio-state.edu> wrote:
> > 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.
Right - the 'modify Proxy' effectively creates a subclass of the original 
Proxy, so 'inherited' in the modifier object inherits from the original 
unmodified Proxy.

> 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.
It's not desirable to have to make those kinds of changes, though.  Part of 
what makes 'modify' useful is that it gives you some degree of insulation 
from library updates.  The insulation can never be perfect, but for this 
particular kind of case, it works quite nicely with ordinary classes.  
Consider a more conventional example:

/* library */
class A: object
  xyz(x) { "This is A.xyz...\n"; }
;
class B: A
;

/* game */
modify B
 xyz(x)
 {
   "This is modified B.xyz...\n";
   inherited(x);
 }
;

Now, if we later download a new version of the library, and that version of 
the library has added xyz(x) to class B, everything still works properly; 
the game doesn't have to know that class B changed.  It would be nice to 
have the same kind of insulation if the underlying library class we're 
modifying happens to be implemented as a proxy.

> It seems to me wholly unclear what the correct semantics are here.  In
> the abstract, both options seem viable.  [...] Without a more concrete 
> example, I don't know how you could say.
Maybe it doesn't matter.  I've had a hard time coming up with a concrete 
example in the proxy case (which is so far the only way the library uses 
propNotDefined) where it makes any difference.  It seems intuitively that 
you'd want the search for the missing-property handler to mimic the search 
for the missing property itself, but I don't have any hard evidence for 
that.  Kevin, if you're reading this thread, do you have any ideas about it? 
 You've done a bunch of stuff with delegation in Proteus that might be 
instructive.

--Mike

_________________________________________________________________
Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage.  
http://join.msn.com/?PAGE=features/es