In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. But hey -- note that, for starters, this would mean that you could easily use an array for caching things... you could give a big hairy calculation as the C<is computed> sub, and immediately store the result in the indexed location -- thus avoiding triggering the computation the next time. Pretty slick.[EMAIL PROTECTED] wrote:Shouldn't access to 'is computed' arrays be read-only?
Assuming, again, your C<is computed> sub didn't return undef. If it might, you still need a separate flag to mean "real undef" vs. "haven't-gotten-around-to-it-yet undef". Which I agree sucks.
Hmm... real vs. fake undef... a difference between null-PMC and PMC-null, autofill with null-PMC, but assigning undef writes PMC-null... is that enough to make it work w/out speed penalty? Dan/Leopold?
But making C<undef @a[n]> and C<@a[n] = undef> do very different things, that's still scary. Powerful, but scary. People really, really want that, huh?
On Thursday, January 30, 2003, at 02:30 PM, Nicholas Clark wrote:
I think there is a lot of scope for creating tied objects for all of this
complex behaviour. Everyone has different ideas about what would be useful,
and they aren't all compatible. Eliminating the speed hit from perl 5 tie
and perl 5 overloading is one big reason why parrot should be nicer to work
with than any language built on the perl 5 internals.
Agreed. Very, very agreed. :-) DAMN, I want to start using this NOW.
MikeL
