John M. Dlugosz wrote:
Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote:
in. Er, so would:
my CGI::Simple $x .= new;
my $y = CGI::Simple.new;
mean that:
$x <whatever the compare class operater is> $y
is not true? Or would there be a way to tell them apart, on a class
(?) level.
The actual dynamic type at run time of the values in $x and $y are
both CGI::Simple.
The static compile-time type of $y is Any.
These are consistent with what I understand.
$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".
$y.nosuchmethod;
will look it up when the attempt is made, and only then fail. (Or
succeed if something funny is going on and it exists =now= but wasn't
declared originally. There are a few documented ways to be funny
already.)
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.
I've kinda come to view Perl 6's types, unless you ask them to be more
than this, as a way of saying "make sure X never can happen at runtime
and complain if it does", as well as giving the compiler more chances to
optimize various things, rather than allowing us to do a load of
type-checking stuff statically and fail at compile time. The "subset"
types can be as complex as you like, so you can't check them statically
at all, since it boils down to the halting problem, which is one thing I
don't think we should require people implementing Perl 6 compilers to
have to solve. ;-)
Jonathan
