We should allow neither "to" nor "from" coercions.
Coercions are not behaviours of a given class. They are interactions *between*
two classes. As such, they are properly implemented as multimethods. So
instead of:
class Foo {
from Bar {...}
}
class Bar {
to Foo {...}
}
my Foo $x = Bar.new; # Bar to Foo or Foo from Bar?
we have:
class Foo {...}
class Bar {...}
multi COERCE (Bar $from) returns Foo {...}
my Foo $x = Bar.new; # means: my Foo $x = COERCE(Bar.new);
or, if Larry doesn't allow return types as part of the multiple dispatch
resolution mechanism, we'd need:
multi COERCE (Bar $from, Foo $to) returns Foo {...}
my Foo $x = Bar.new; # means: my Foo $x = COERCE(Bar.new, Foo);
(which is a good reason for Larry to allow return types as part of the
multiple dispatch resolution mechanism, IMHO ;-).
Damian
Keep in mind that Perl6 have a three layered type system if I
understand things correctly.
Types are not necessarily classes.
I think all this thead does not take in account that perl6 has a
three layered types system; layers that I respectively call raw, boxed
and warped (roughly defined below). Is there an official nomenclature for
them? It would help.
Raw types are C<int>, C<num> ... boxed typed are provided by PMC. In
fact, even if they usually are jitted, raw types are implemented in
term of boxed types so they should behave the same way as far as
conversion/coercicion is involved. Keep in mind that we may want to
directly access PMC implemented for other languages from Perl6. What
will be the Perl6 syntax BTW? C<PMC is pmcname $varname> for a scalar
PMC? Warped types are whatever languages specific types build on top
of PMC; probably to implement whatever OO semantic.
The current thread talks about raw types, boxed types and perl6 warped
types as if they were the same thing. I undersdand we may want
consistency but I am not sure it is always possible/desirable if we
take in account PMC for foreign languages and performance
consideration.
I know that p6l and p6i are not the same list but Perl6 language will
have some underlying implementation that we should take in account.
Damian and Dan, can you shade light on that? What is the correct
nomenclature for what I call raw, boxed and warped?
I like these words because they not yet have OO meaning (except for
boxed in .Net) so people are non confused by implicit expectations.
But warped does not mean warp speed. Warped types have to cost more
than raw types.
--
stef
Agreed, that would be fine. My preference for "from" and "to" are
merely syntactic sugar, but the effects would be identical.
> (which is a good reason for Larry to allow return types as part of the
> multiple dispatch resolution mechanism, IMHO ;-).
Yes, amen, please.
MikeL
Sic quoque dico.
Or, in case my Latin sux today: "Ditto!"
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com