> 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.
That would increment a regular integer too, though.
Am I misinterpreting constant reference? That is, is it a reference
to a constant or is the reference itself constant? IIRC it's the
latter...
> > 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.
Well, I think the difference is that assign puts the burdon on
PerlUndef, while valclone puts the weight on the thing being
cloned/assigned. If we don't like type switches, the the clonee is
probably a better place to put it.
But then, set_pmc() could always call a method on its argument. That
means that there has to be an appropriate vtable entry to call,
though... like, um, valclone :-)
> > 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.
I'm not sure either, but I'm also not sure if we don't need it. Which
is why I'm taking the time here to explore/discuss it.
Luke
