[M3devel] calling an overridden method

[Mika Nystrom]

Right, a shadowed method is a new method of the same name, just like
Algol block structure.  An overridden method is a different binding for
the same method.  If you override a method, you can't call the old one 
without using the special A.T.m(a,...) syntax, since there's no binding
for the old one within the type record for your object.  The A.T.m(...)
syntax works whether the method is shadowed or overridden.  The widening
only works for shadowed methods.  

The clever thing is that the method dispatch is based on the known type
of the object within the context that the method is called, not where the
object type is declared.

This distinction between overriding and shadowing I think is one of the
most brilliant aspects of Modula-3: it avoids the problem that you
create an unwanted method override by adding a new method of the same name
(whether in a supertype or a subtype).

     Mika


Hendrik Boom writes:
>On Tue, Jul 19, 2011 at 01:26:14PM -0400, Hendrik Boom wrote:
>> On Tue, Jul 19, 2011 at 07:11:05AM -0700, Mika Nystrom wrote:
>> > Sorry I'm being confusing here.
>> > 
>> > The code is right but I think your question is a bit confusing.
>> > 
>> > With your init example I don't think you're talking about an overridden
>> > init method but a shadowed method.
>> 
>> A 'shadowed' method.  Is that what you call what's essentially a new 
>> method that happens to have the same name?  Just like the way a variable 
>> in a nested block that has the same name as one in an outer block would 
>> be a new variable (I'm not sure Modula 3 allows this, the way C and the 
>> Algols do; I find it leads to confusing code).
>> 
>> Init is the one I've seen explained in documentation.  It's  not what I 
>> want, because that trick provides no inheritance.
>> 
>> > You can't call an overridden method
>> > through the widening trick, but you *can* call a shadowed method like
>> > that.
>> > 
>> >      Mika
>> > 
>> > Mika Nystrom writes:
>> > >
>> > >TYPE A = OBJECT METHODS m(xxx) END;
>> > >
>> > >TYPE B = A OBJECT METHODS m(xxx) END;
>> 
>> This is, if I understand the terminology, a declaratin of m as a shadowd 
>> method.  It's not what I want, because I  intend that under normal 
>> circumstances, if an B object is used in a context where its static type 
>> is known as A, I still want the normal overriding mechanism to ensure 
>> that B's m is the one called.
>> 
>> I mean something like
>> 
>> TYPE B = A OBJECT OVERRIDES m := ... END;
>> 
>> > >
>> > >b := NEW(B);
>> > >
>> > >A.m(b,xxx)
>> 
>> So this is a way to specifically get the m that belongs with A?  Will 
>> this work with the way I want to define B and m?
>> 
>> as in
>> 
>> TYPE A = OBJECT METHODS m(xxx) := bar END;
>> 
>> TYPE B = A OBJECT OVERRIDES m := foo END;
>> 
>> PROCEDURE foo(self : B, ....) =
>> BEGIN
>>   ...
>>   ...
>>    A.m(self, ...)   (* and this ends up calling bar? *)
>>   ...
>> END foo;
>
>Well. I tried my version, and it works.  Thanks for the advice.
>
>-- hendrik
>
>> 
>> > >
>> > >      Mika
>> > >
>> > >Hendrik Boom writes:
>> > >>I have a module containing a parent class, and another containing a 
>> > >>child class.
>> > >>
>> > >>The parent class contains a method 'foo', which is to be overridden in 
>> > >>the child class.
>> > >>
>> > >>But in implementing 'foo' in the child class I want to call the parent's
> 
>> > >>method.
>> > >>
>> > >>Now with the method 'init' there's a trick where in the child's init,
>> > >>you WIDEN self to the parent's type and then call its init.
>> > >>This works because 'init' isn't overridden in an OVERRIDES clause,
>> > >>but is defined as a new method that happens to have the same name.
>> > >>
>> > >>Is there any way to do this with 'foo', where the whole point is that
>> > >>it be an overridden method and not a new one?
>> > >>
>> > >>Do I have to do something like covertly exporting the PROCEDURE that 
>> > >>implements 'foo' in the parent's module so that it can be called 
>> > >>directly? That would seem to be a violation of modular design.  Or is 
>> > >>violating modular design exactly what I'm really trying to do here?
>> > >>
>> > >>-- hendrik