I want to make an loose analogy between pmc/their_content and
Unix inodes/files which I use as a mnemonic.

PMCs are the equivalent of inodes, each one
reference some content which is the equivalent of a file.

C<set_pmc>, when the source and the destination pmcs are of the same type,
is like creating a hard_link to a file. The two pmcs share the
same content.

C<set_pmc>, when the destination pmc is a reference, is like
creating a symbolic link with the difference that there cannot
dangling reference pmc thanks to reference counting.

C<assign_pmc> is like copying a file to another. After the
assignement the two pmcs and their contents are independant.

Does the analogy holds? or am I mistaken?
I certainly don't pretend that one can carry further the analogy.

--
 stef

,--[ pdd02_vtables.pod ]------------------------------------------
|       void set_pmc(INTERP, PMC* self, PMC* value)
|            Sets the value of the PMC in self to the value of the
|            PMC in value.
|
|        void assign_pmc(INTERP, PMC* self, PMC* value)
|            Sets the value of the PMC in self to the value of the
|            PMC in value by copying the value.
`-----------------------------------------------------------------

So probably yes. OTOH having e.g. two array PMCs pointing to the same
array structure could be rather error prone.

I think, we have to consider first variables vs values. Variables have a
name and hold values (the PMCs). It depends on the HLL, what e.g. an
assignment is doing:

  i = j   # Python - both variables refer to the same value
  i += k  # mutable objects are changed in place
          # immutable objects are rebound to hold the new value
  @a = @b # Perl - copy array

So normally setting a value happens one level higher. But in leaf
functions and in the absence of introspection, I can imagine that the
optimizer converts lexical opcodes to PMC-only operations, depending on
the semantics of the HLL.

leo

At 12:06 PM +0200 10/27/04, Leopold Toetsch wrote:

Not quite. The PMC is the variable, not the
value. The contents of the PMC are the value.

These aren't all assignment, and the chosen punctuation is really unfortunate.

This isn't assignment. This is name rebinding --
that is, two names in some namespace refer to the
same PMC

This is one of those bizarre mutant cases -- it's really a method call.

This is assignment, sort of. If you squint hard,
given the stuff perl's doing behind the scenes.

In all these it's important to note that in most
languages (certainly the ones we care about)
objects are *reference* types, not value types.
That is, there's a level of indirection (likely
an ObjectReference or just generic PMCReference
PMC) between the name and the ultimate object
structure, something we don't do right now.
--
                                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk