Hi,
I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right.
Nope, actually they don't have to be. Simon was correct here. Accessing an element of an aggregate returns the PMC pointer of the thing in that slot. If the aggregate itself does Magic Things when something is fetched out of it, the PMC it returns should be one that does the appropriate slot-specific Magic Thing when accessed.
Assuming,for all the future examples, that %foo is a Magic Hash (and we're using Perl 6 syntax), this:
%foo{bar}
should return a PMC (which is then discarded) that would give you whatever value you'd get from the bar slot of the %foo hash.
Since assignment is really copying, this:
$baz = %foo{bar};
fetches a PMC that does magic things out of %foo, extracts the value (presumably non-magic) out of it, and assigns that value to $baz. (Which itself might have Magic on it, but we're not going there right now) At the end of the statement the Magic PMC goes away. (give or take a bit with DOD runs)
This, on the other hand:
$baz = \%foo{bar};
gets the magic PMC out of %foo, then takes a reference to it. That reference goes into $baz, and the magic PMC fails to go away.
Now, what happens when you fetch the value out of that referred-to magic PMC? Well... that depends. Probably the identical same thing that would happen in the assign case, but whoever writes the class for %foo that builds the magic PMCs that get returned needs to do the right thing and put enough state information into the pmc to return the data properly.
It would, however, *also* be perfectly appropriate to have the value returned from %foo{bar} to *not* be magic, and in fact be a plain old PMC, in which case multiple accesses to it will return the same static data.
Depends on how the class wants to handle things, really.
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
