Re: Are array based objects fixed length?

[BrentDax]

I'd suggest that in the general case you use a Pixie::Array wrapper with an overloaded @{} operator. The overloaded @{} would return the host object's data; Pixie would know how to get its stuff out of a Pixie::Array.

Or something like that. It's a pretty hard problem. *shrugs*

<thought type="evil">Could you set up an overloaded @{} in UNIVERSAL that would implement this behavior? That would solve the problem of Pixie::Array's blessing. Alternatively, Pixie::Arrays could keep track of their "real" blessing and redispatch:

package Pixie::Array;

sub PIXIE_getoid { return shift->{oid} }
# ...
sub AUTOLOAD     { return shift->{realobj}->$AUTOLOAD(@_) }

</thought>

=cut
--Brent Dax
There is no sig.

[pdcawley]

The problem with overloading @{} in UNIVERSAL is what happens when one of the storedclasses has overloading in place?

I have already discovered to my cost that reblessing and overloading do not play well together; you get all sorts of painful spooky inaction at a distance (ie: The spooky action at a distance you were hoping would happen doesn't).

However, my boss recently played a blinder when he had the idea of using XS to hang sv_magic off the object which, (after a certain amount of buggering about due to problems with sv_unmagic being a little, well, eager) combined with a weakref back to the object for DESTROY convenience gives us what we need. And, marvellously, it dramatically simplifies our object tracking and caching code and removes the need to rebless into a 'managed' class. Now the only reblessing we need to worry about is when a proxy object gets restored.

This is probably not the place for a Pixie walkthrough though. I'll see about preparing a meditation on some of the tricks we get up to in order to 'just work' for the client.