On Tue, 2005-03-29 at 16:00 -0700, Luke Palmer wrote:
> Unless the caller can't see the signature, as is the case with methods.
I need to understand this piece.
In this code:
class X {
method meth() {...}
}
class Y is X {
method meth() is rw(int $r) {...}
}
sub foo { return my Y $tmp }
my X $a = foo();
$a.meth() = 8;
What happens? Do we impose a compiler-level restriction on the call that
prevents this, or do we always allow it, and let the run-time take care
of it?
My preference by far is to let the compiler tell you that it's illegal
because there's no valid reason for a sub-class to change the semantics
of a polymorphically invoked method like this. The sub-class might
introduce new semantics, but when manipulated as a base-class those
semantics should only come into play when they are invoked via the
interface of the base class. That sounds like an almost axiomatic truism
to me, but if I read what you wrote correctly, you don't seem to agree.
It's important to look at this as a two(more?)-stage process with
different agendas and limitations, no?
More generally, I think it's always a valid thing for the compiler to
impose the restrictions of the type it knows about, regardless of what
polymorphism might discover later on at run-time. This means that you
can't do this:
class X { }
class Y { method m (int $a) {...} }
my X $ob = get_me_a_Y();
$ob.m(1);
because X does not provide an m.
> Again, this can't be done unless you know the signature. And in fact,
> we can't do type inference on methods unless we do type inference
> everywhere, which we can't do if we want an autoloader.
You can combine and autoloader with type inference. You may not choose
to, but it's not impossible. You can load the signatures ahead of time,
and link the code at run-time. What gets dicy is this:
eval "use X";
my X $a;
$a.m(1);
I think that's invalid too, but I'm not sure.
