Object semantics

[Dan Sugalski]

Okay, I've been working on getting bytecode generation nailed down, and then digging into the vtable split stuff, but I thought I'd specify at least a little how objects (this would be real language-level "we're object-oriented dammit!" objects, not the lower-level stuff we're currently working with) should/will behave.

Parrot, like all the OO languages that will live on top of it, uses reference-style objects and non-reference values. The difference here is that on assignment values are cloned and references are copied. If you do this:

a = b

and b is a value, a will have a copy of the value in b, but it'll be in a different location in memory, and changes to b won't affect a.

On the other hand, if b is an object, then a and be refer to the same object, and actions on either a or b affect the other. (This is nasty action at a distance, and I really don't like it, but nobody asked me here :)

We are going to muddle things some by having value objects in addition to reference objects, as arguably all the values that are in PMCs can be treated as value objects. (When those PMCs hold references to reference objects, the copied value is just an address so the destination object, and thus our value objects handle the case of being the front half of a reference object just fine)

Still, for 'real' OO, it's all reference object stuff, so things should Just Work. The pending questions about ruby assignment work out since, while the assignment part of vtable behaviour's potentially troublesome, it doesn't make any difference since what you're assigning into is the front half of a reference object, and thus you get pointer-to-pointer semantics the way you want. (And if it's not, then it should do the right thing on assignment, which may be... interesting in a mixed-language environment)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk