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:
Aaron Sherman
Date:
March 30, 2005 11:30
Subject:
Re: Parameter and trait questions - just how 'only' _is_'read-only'?
Message ID:
1112210995.7453.19142.camel@pps
On Wed, 2005-03-30 at 13:53, Luke Palmer wrote:

>     class CodeProxy {
>         has Code $.code is rw;
>         sub call ($a) {
>             $.code($a);
>         }
>     }

> This is valid Perl 6, and anyone who says otherwise (because of type
> signatures) is changing the Perl philosophy too much to be taken
> seriously.  Now, tell me at compile time whether the call inside `call`
> is valid.

It's valid because it's a function call on a code ref. In that case, the
compiler has to hand your request off to the run-time to check the
vtable of $.code. Clearly that's a special case. I may have missed
context at the start, but are we worried about the special cases or the
general case or the implications to the general case of the special
cases?

> At runtime, you load in a new subclass of `CodeProxy`, `DoubleCodeProxy`
> (this programmer apparently doesn't know that we support variadic
> signatures :-)

I think this is where you're stepping off the path I thought we were on,
and I agree with the rest of your message FOR ONE CASE, but not all.
Runtime loading can happen in many ways, but let's break them down into
two camps: with and without a compile-time interface definition. In the
first camp you have autoload. In the second camp you have low-level
(e.g. Parrot) code that happens to have no interface definition (because
it's pure PBC or because it came from another language) and evaluated
strings.

What I do not think should be allowed (and I may be contradicting Larry
here, which I realize is taking my life in my hands ;) is violating the
compile-time view of the "static" type tree. That is, you can load an
object "foo" at run-time, without and interface definition, but it can't
change the shape of the type tree or its existing interfaces. If it
wants to do that, it has to provide an interface def (e.g. what an
autoload module should be able to provide).

Why? Because if you can do that, then this:

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

ALWAYS has to work because you might have replaced X at run-time with a
class that has a "method m(int) is rw()", and the compiler must silently
(perhaps with an optional warning) permit it.

Please think carefully about how dynamic you want Perl 6 to be....
Dynamic is good, but there's such a thing as too much of a good thing.

-- 
Aaron Sherman <ajs@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback



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