Front page | perl.perl6.language |
Postings from May 2008
Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote:
>> $x.nosuchmethod;
>>
>> will give a compile-time error if nosuchmethod is not declared as
>> part of CGI::Simple.
> Is this spec'd somewhere? I don't think we can statically know what
> methods CGI::Simple will have at compile time. What if I do a "class
> CGI::Simple is also { method nosuchmethod() { ... } }" inside an eval?
> Then it does have the method by the time we get to instantiating it,
> and calling the method. I think Perl 6 is just too dynamic to do these
> kinds of checks, without using some kind of additional (not the
> default) pragma saying "I promise that classes don't get changed at
> runtime".
>
Precedent in the synopses thus far mention knowing what is in the class
thus far, including non-wildcard delegations.
The formal wording of what happens in every case is my own particular
interest. None of the notes I've made from this list's discussions
address this beyond above precedent for related issues.
Implementation-centric thinkers want to be assured of making dispatch
tables ahead of time, and the whole idea of declaring a type is to get
compile-time checking that you don't mistype a method name!
Now if I can brainstorm a bit,
a failure at compile-time will alert you to the problem that "something
funny" is happening, without the need for full run-time coverage testing
to spot it for you. Normally you see you used the wrong object,
misspelled the name, or whatever. If you decide "Oh, that's a funny
case" then you deliberately indicate that you want to try anyway at
run-time, on that particular call, and re-compile.
After all, you chose to enable strong type checking on that particular
passage of code. That's what it's for.
> Right, but I don't know that being funny should preclude you from
> being able to write a type constraint on a variable that makes sure we
> never assign anything to it that isn't "compatible" with CGI::Simple.
> Making "$x.nosuchmethod;" fail at compile time by default would stop
> you using them that way in the cases where there are more subtle
> things going on.
So you want a type label that says "these objects are meant to be in a
particular set of objects" so you don't pass the wrong one or assign one
to the wrong variable, but not to apply any meaning to that type beyond
that.
I can see applying the generics mechanism to check the code at the time
it is called, not at the time it was defined, in case the type changes
meaning. But that doesn't flush and re-apply if the type changes
again. You can derive a new class just to give it a distinct type, to
pick up changes. I see a variety of techniques for maintaining strong
typing and earliest checking in light of open classes and reusing code
that was compiled too soon. I can also see simply not using the strong
checking features when that is getting in the way rather than helping.
my $y = $x;
$y.nosuchmethod; # forget strong type by using another variable
$x.?nosuchmethod; # explicitly do run-time lookup if it wasn't found
no typecheck :methodcall # turn off in scope
my CGI::Simple ::Realtype $y = $x;
# specialize generated code based on actual contents of type now.
$y.nosuchmethod; # OK, I see it as part of Realtype
--John
Thread Previous
|
Thread Next