On Wed, 27 Aug 2003, TOGoS wrote:
> > The part that affects us is that we can't tell at
> > compiletime whether
> > assignment is rebinding or is a get/set, because we
> > could have code
> > like:
> >
> > kitchentemp = new('kitchenroom');
> > bedroomtemp = new('bedroom');
> > bedroomtemp = kitchentemp;
> >
> >
> > which is typeless, and yet should still respect the
> > fact that the
> > objects bound to the name intercept assignment
> > (basically overloading
> > it) rather than having the compiler or runtime doing
> > the rebinding
> > for you.
> >
> > Since, of course, we're dealing with basically
> > typeless languages we
> > have to do all the checking at runtime (lucky us)
> > which is why the
> > PMCs have generic get and set methods so they can
> > decide whether
> > we're doing rebinding or something more funky.
>
> Humm. Are you saying that whether 'set' does binding
> or 'morphing' on a PMC will not be known at compile
> time at the PASM level? So we don't know exactly what
>
> set Px, Py
>
> will do?
No. Set copies the pointer from source to destination. That's all it's
ever done, and what it's supposed to do.
> Maybe there should be 3 'set' ops: 'assign'
> which changes the object, 'bind' which
> replaces it, and 'set' which does whatever
> the heck the object wants it to do...
We already have this. Assign will copy the value in the source into the
destination PMC, and the destination is free to do what's needed to make
things work. The various lexical and global namespace stores are the
binding changes.
Most objects in Parrot will be dealt with by reference, which is to say
that the PMC that a name is bound to is not an object, but rather a
reference PMC that points to the object PMC. An assign, in that case, just
copies the value in the source reference (which is the pointer to the
referred to object) into the destination reference, so it all works out
OK.
I think I need to put together something more detailed on how this works,
though. I expect this explanation will just make things more, rather than
less, confusing.
Dan
