Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>NI> Indeed that is exactly how tied arrays work - they (automatically) add
>NI> 'p' magic (internal tie) to their elements.
>
>Hmm, I always understood a tied array to be the _array_ not each individual
>element.
The perl level tie is on the array. That adds C level 'P' magic.
When you do an access to an array element the 'P' magic adds 'p' magic to
a (proxy for) the element. The 'p' magic invokes FETCH or STORE.
It does not have to be that way - but it is in perl5.
>
>NI> Tk apps to this all the time :
>
>NI> $parent->Lable(-textvariable => \$somehash{'Foo'});
>
>NI> The reference is just to get the actual element rather than a copy.
>NI> Tk then ties the actual element so it can see STORE ops and up date
>NI> label.
>
>Would it be a loss to not allow the elements? The tie would then be
>to the aggregate.
Yes it would be a loss. If only one element in a 1,000 entry array
is being watched by a widget that is a LOT of extra work checking
accesses to the other 999 elements. You would also have to allow
1,000 ties on the SAME array so that 1,000 widgets could each watch
one element. Or force higher level code to implement element watching
by watching the array and then re-despatching to the approriate inner
"tie" - which is what we have now ;-)
>
>I might argue that under threading tieing to the aggregate may be 'more'
>correct for coherency (locking the aggregate before accessing.)
I don't disagree - the lock may well be best on the aggregate - but that does
not mean the tie has to be.
--
Nick Ing-Simmons
