Luke Palmer <[EMAIL PROTECTED]> wrote:
> Consider this Perl 6 code:
> sub refinc($var) {
> my $myvar = $var;
> $myvar += 1;
> }
> If you pass an integer in here, it should do nothing. However, if you
> pass an object with an overloaded += in, it should have the
> side-effect of adding one to that object. It's just a value/reference
> semantics thing.
AFAIK no. The default is to pass constant references as arguments. So I
would expect this throwing an exception.
When you have:
sub refinc($var is rw) {
it should increment the object ref.
> If Perl compiles that code with $var and $myvar as PMCs, and it uses
> C<set> to get $var into $myvar, PerlInt won't work right. And if it
> uses C<clone> to get $var into $myvar, an object won't work right.
I think the assignment would translate to:
$P0 = new PerlUndef
assign $P0, $P1
Its now up to the set_pmc() vtable to do the right thing for an object
reference.
> There are two ways to solve this: make a PerlRef class (which will
> eventually have to be done anyway) or make a polymorphic assignment
> which lets the PMC decide whether it has value or reference semantics.
We need both, yes.
> The included tentative patch implements the latter (namely,
> C<valclone>).
This is AFAIK what C<assign> does anyway.
>> PMC* valclone () {
>> PMC* dest = pmc_new(INTERP, SELF->vtable->base_type);
>> memcpy(&dest->cache, &SELF->cache, sizeof(UnionVal));
>> return dest;
>> }
I'm not sure, if we need this.
leo
