Re: [Tads3] 'inherited' and propNotDefined

[BrenBarn@xxxxxxx]

Jesse Welton wrote:
-----
Perhaps something like this:

  class ShadowProxy: object
    target = nil
    propNotDefined(prop, [args])
    {
      return delegated target.(prop)(args...);
    }
  ;

Now, for this to be widely useful, we'd need some way to intercept
property assignments.  We don't have these, and maybe we never will.
That's why this is only a "fairly good" example and not an absolutely
convincing practical example.  But it still provides a more concrete
case to think about.  With that in mind, suppose we have an object
that uses propNotDefined for some other purpose.  For concreteness,
let's say error reporting.

  a: object
    propNotDefined(prop, [args]) { "prop not defined: <<prop>>" }
  ;

  p: ShadowProxy
    target = a
  ;

If we call p.xyz(), we get p.propNotDefined(&xyz), which delegates to
a.xyz().  When we find that missing, lookup of propNotDefined must
proceed from a, not p, for correct behavior.  For consistency,
inherited lookups should proceed the same way, from the target.
-----

       I see your point, but I don't think this example really parallels the inheriting-undefined-properties situation, because there's no explicit inheritance call.  This has got me thinking; let me give my perspective here.

       My thinking is that, for the purposes of resolving this issue, we should consider inherited() as nothing more than a convenient textual substitution for an explicit call to the corresponding method on the base class.  It relives us of the burden of having to manually sync the method name and class name (and it keeps the same self object and so forth) but essentially it is a call to a specific other method.  To wit:

class A:
       abc() { "This is A.abc"; }
;

a: A
       abc() {
             "This is a.abc";
             inherited();
             // the above line is bascially a convenient way to write 
             // A.abc();
       }
;

       To me, this clearly indicates that inheriting-into-a-propNotDefined lookup should NOT proceed from the target.  The inherited call should always be a call to the method of the base class, and should be looked up accordingly.  If no such method is found, propNotDefined should be called on the base class, because that's where we were looking for the inherited method.

       In addition, I think it might be fruitful to look for examples where we definitely would NOT want the inherited lookup to find a propNotDefined on the target object.  (I had an example but I think it was pretty hairbrained so I'll keep thinking.)  It seems that there could be situations where "inheriting" a propNotDefined on the target object would incorrectly delegate to the proxy object when what was intended was to inherit base class handling for the target object.

       I do, however, agree that it would be better to avoid a separate propNotInherited and stickwith propNotDefined.
--OKB