develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
From:
Luke Palmer
Date:
March 30, 2005 08:37
Subject:
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
20050330164026.GA14484@navi.cx
Aaron Sherman writes:
> 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.

No, I think I agree with you here.  But what happens if you change
you're second-to-last line to:

    my $a = foo();
    $a.meth() = 8;

Perl 6 is both a statically typed language and a dynamically typed
language, and the problems that I am addressing are mostly about the
dynamic part.

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

Again, that's invalid in the static world, but it should work if you
s/my X/my/.   The kinds of type inferrence people are saying would solve
our problems require us to infer code like this, which we can't do.

There _is_ a way to do it, actually, but we need to really screw around
with what kinds of things are inferred.  In the case:

    my $a;
    $a.m(1);

We assign the type "objects with an 'm' method that can take a single
integer" to $a.  This is a category of objects that spans many classes,
and does not fit into a nice little tree.  I think that before we take
on such an idea, we should look for research about this kind of type
inference.

Luke

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About