TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibility. Like reinterpret_cast in C++.
I've not gotten that far yet, but I do envision a way to test for
conformance rather than mix-in to create conformance and change things
around. There might be a more primitive operation for doing than than
binding a capture to a signature.
I also envision that this can give the compiler information that it uses
to make a cached dispatch table, but this is not visible to the user.
It just means that declaring your types, even "duck types" will not only
give compile-time checking but speed up calling for that variable.
But either the HOW, the WHAT or both of $fp have to change
which implies that $y === $fp can't remain true after
$fp does Point. BTW, an interesting question is if a typed
binding could become invalid:
subset AntiPoint of Any where {not .^does(Point)}
my AntiPoint $ap := $fp; # fine for now
$fp does Point; # now $ap is bound to a Point which
# violates the AntiPoint constraint
It's not different than
my Int $y = 5;
subset X of Int where { $_ < 5 }
my X $x := $y;
++$y;
The subset is part of the type of the item container. You alias it to
something which is a different type of container. How can such aliasing
ever be other than non-variant to be correct, unless the alias is read-only?
That's no different than defining a symbol with container type
MyTiedItem and then trying to alias it to a plain Scalar. Type mismatch
in the := operation.
--John
