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