In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so let's write it as
>
> set P1, P2
>
> Excellent. Until, of course, we have to implement it. We'll implement
> it by calling some vtable method on P1, that much is obvious. But which
> one?
Actually I don't think that it is obvious at all.
I see three cases.
Both $a and $b are untyped ("my $a;"). This is easy, duplicate $b and its
dynamic type (e.g. $b is a reference to a hash, then $a becomes another
reference to that hash; $b holds an int then $a will hold a copy of that
int).
Both $a and $b and typed, with the same type, this is the other easy
case---copy the value again.
However if $a and $b are of difference types (e.g. $a is an int and $b in
untyped, or $a is a string and $b is an reference to an array of snafu).
There could be two ways of writing this: $a does the conversion (has a
"set_from_xxxx" method), or $b does it (has a "get_as_yyyy" method). Given
dynamic loading and adding extra types, the types may not know about each
other when those types were implemented.
In the worst case, types created independently without any knowledge of
the other we can only do something like "stringise and unstringise" or
raise a "don't know how to convert error" (quite possibly at compile
time).
If one type knows about the other then it should be possible to ask it to
do the conversion (and some sort of arbitrary "assignee's conversion wins"
in case of both ways possible). Thus given:
my snafu $a = Something();
my foobar $b;
$b = $a;
the compiler tries:
does foobar have a set P1, P2, "snafu" method?
yes -> use it
does snafu have a get_as "foobar" method?
yes -> use it
else see above (go via some intermediate type or error)
The trick is likely to be balancing complex rules about conversions (look
at C++98 for an example of how complex this can be and what to avoid)
while DWIM to a sufficient degree (for some definition of sufficient).
The point of this messaging really being, that we need to allow
types/classes to define how they convert to other types and since this is
not known at the time of creation of the other type (let alone Perl6) we
need a certain degree of "see what the types will do".
Richard
--
[EMAIL PROTECTED]
