Re: [Tads3] 'inherited' and propNotDefined

["Kevin Forchione" <kevin@xxxxxxxxxxx>]

----- Original Message ----- 
From: "Mike Roberts" <mjr_@hotmail.com>
To: <tads3@v-space.org>
Sent: Thursday, September 11, 2003 1:24 PM
Subject: Re: [Tads3] 'inherited' and propNotDefined

>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.

That seems right to me as well. Because you've defined xyz(x) on the object,
so propNotDefined() shouldn't catch it on that object.

However, if you've then passed control to anther object, and that object
doesn't define the property, there are some cases that I can think of:

class A: object
  propNotDefined(prop, [args]) //...
;
class B: A
  propNotInherited(prop, [args]) //...
  xyz(x) { return inherited(x); }
;

I've modified the original code from your previous example to illustrate my
point. Here If we call property xzy(x) on class A then I would expect
propNotDefined() to pick it up, because that's what we've done, we've called
a property on the class and it's not defined on the class.

However, If we've called that property through inherited() from another
class. Then I would either expect it to be handled by propNotDefined() in
class A; or (it seems to me the better design) have propNotInherited() catch
the call on class B.

If that were the case, the question then involves nested inherited() and
where the capture would take place. If, for instance, we have the following:

class A: object
  propNotDefined(prop, [args]) //...
;
class B: A
  propNotInherited(prop, [args]) //...
  xyz(x) { return inherited(x); }
;
class C: B
  propNotInherited(prop, [args]) //...
  xyz(x) { return inherited(x); }
;

Now, which propNotInherited() should catch the fact that class B doesn't
inherit xyz(x)? If class B defines propNotInherited() then perhaps that
method should catch the call, but if class B *didn't* define
propNotInherited() then perhaps class C's propNotInherited() should catch
the call.

In a sense, I'm picturing propNotInherited() as working up the inheritance
tree in a way analogous to how a throw would work its way up the call chain,
with the exception that the chain would terminate at the class that
initiated the first inherited().

Does this make sense? Or is it something that is way off base in terms of
semantics? To clarify:

    a. propNotDefined() would be clean: caught on the object being called
when the property is not defined on that object.
    b. propNotInherited() only used when inherited() is used, called for the
"lowest level" class in the inheritance chain where propNotInherited() is
defined.
    c. propNotDefined() takes precedence over propNotDefined() when there is
the case of the proxy defining propNotDefined() and the calling object
defining propNotInherited().

--Kevin