in reply to Re: Class::InsideOut - yet another riff on inside out objects.
in thread Class::InsideOut - yet another riff on inside out objects.

In general, I like your approach - a lot.
<blush />
One thing that annoyed me is the $self->self meme.

Me to, but like you I cannot see a way round it. I've just renamed it self_id in my local version.

That aside, here's my take on the base class - minus refaddr cause it doesn't work on 5.6.1.

Are you sure? It's basically the same implementation as the one here.

What I do is quite simple: store the hashref to the pad :-). Then all that AUTOLOAD has to do is trawl through the pad hashrefs and look for a matching attribute.

Falls over completely on 5.8.0. Probably because of this :-)

I like your use of an array to store the class hashes in. Makes the logic easier to understand. Might be a problem in the context of serialisation - since the position of the hash depends on the load order of the classes used by your application. You could always store a class->position mapping I guess.

I don't know if it's watertight, though. In particular, how well will it work if I call an accessor for a superclasses' field on a subclass?

There's the begining of a test suite in the version at if you're interested.

  • Comment on Re^2: Class::InsideOut - yet another riff on inside out objects.

Replies are listed 'Best First'.
Re^3: Class::InsideOut - yet another riff on inside out objects.
by Aristotle (Chancellor) on Dec 19, 2002 at 17:26 UTC
    Falls over completely on 5.8.0.


    I did not think about serialization at all when I moved to an array - there was a very simple reason for that - my first step was, since you're not using the $class in your while in DESTROY, to make that

    delete $_->{id} for map @$_, values %Values; At that point I blinked, looked hard at the entire source I had in front of me, which didn't include ::YAML, and saw there was nothing to ever make use of the key - obviously an oversight. I haven't looked at the ::YAML code at all yet (not the least reason being I haven't dealt with at YAML at all yet either) so I'm not sure if that will work, but a simple way out might be an extra hash keyed on the refaddr of the fieldhashref and storing arrays of classnames. I'm just pulling straws out of thin air here though.

    Makeshifts last the longest.