Inside out objects and persistence

I've recently got to grips with Damian's version of inside out objects, reading Perl Best Practices, and his examples using Class::Std. Although I don't have an immediate application, some ideas clicked with another train of thought I had a couple of years ago regarding object persistence.

I started off by realising that inside out objects won't allow a serialiser to break encapsulation. This is the usual way that Data::Dumper, Storable, YAML, etc. serialise blessed-hashref type objects, by treating them as data structures, but tagging the class name so that they get blessed when thawed. This is solved by supplying custom freezer and toaster methods (or equivalent) within the inside out object.

The freezer method is an object method, turning the object's guts into a string or a list. The toaster method however is a constructor class method, which will rebuild an object from the serialisation string or list.

I recalled a problem with object persistence, in that retrieving a given object twice yields two different objects but with identical contents. If one of the objects gets modified as a result of some actions, or indeed if some other process modifies the objects in the backing store, the other object has stale data, and no means of knowing that the data has changed.

My idea at the time was for the class to keep a registry of objects and ID keys, so that if you asked for the same object twice, you got a reference to the same object. I've since noticed that Class::DBI and its lower level modules - Ima::DBI, DBIx::ContextualFetch, do just that. But my needs are more general purpose than an object relational mapping.

Now, looking at inside out objects, all your object is, is a lookup key anyway, with the object data being hidden away in class lexical padspace. Damian uses a blessed scalarref for the "object", not ever using the scalar's value for anything.

It has occurred to me that I could use the scalarref's value to be the ID key for the object, which gives an added bonus of easy stringification. I would be looking at providing a different ident sub to gain access to the attributes, to use the ID (contents) instead of the scalarref's address.

Managing the cache of objects is a nice fit with Damian's DEMOLISH method.

Thoughts please. Am I barking up the wrong end of the stick? Is someone working on something similar already?

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)

Comment on Inside out objects and persistence

Replies are listed 'Best First'.
Re: Inside out objects and persistence by xdg (Monsignor) on Jan 03, 2006 at 17:57 UTC
These are known issues. For persistance, Object::InsideOut and Class::Std::Storable both offer Storable hooks. (Also see my digression today: Hooks like Storable for Dumper?). I plan on covering a lot of this at my Inside-Out Tutorial at the January Perl Seminar NY. Here's a snippet from my presentation -- you've really got four options for how to implement the storage/index of inside-out objects: Array-based storage, with sequential object ID's stored in blessed scalar Hash-based storage, with a generated unique object ID cached in a blessed scalar Hash-based storage, with memory address of a blessed scalar cached in the scalar Hash-based storage, with memory address of the blessed reference used directly Each has pros and cons. There's some discussion on using memory addresses versus a UUID in Threads and fork and CLONE, oh my!. The latter is probably the way to go if you want to check if the object thawed is the same as an existing object. For another good summary of inside-out issues, read Anti-inside-out-object-ism -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re: Inside out objects and persistence by perrin (Chancellor) on Jan 03, 2006 at 17:25 UTC
All that you need in order to ensure object uniqueness (at least within a single process) is a method for uniquely identifying an object. If you add some kind of id() method to all your objects, it won't matter how they are implemented.	[reply]
Re: Inside out objects and persistence by phaylon (Curate) on Jan 03, 2006 at 17:00 UTC
I'm really walking in the dark here, but I think Object-InsideOut let's you choose how to identify an object. IIRC Class-Std is bound to it's refaddr. Shoot me if I'm wrong :) Ordinary morality is for ordinary people. -- Aleister Crowley	[reply]
Re: Inside out objects and persistence by Perl Mouse (Chaplain) on Jan 03, 2006 at 23:22 UTC
It has occurred to me that I could use the scalarref's value to be the ID key for the object, which gives an added bonus of easy stringification. That would deny any other class in the inheritance tree to pick its own implementation. One of the nice things about Inside-Out objects is that a subclass or a superclass can use traditional objects to do their implementation. Given that Storable has hooks to deal with cases where classes have proper encapsulation, IMO, that's a heavy price to pay. `Perl --((8:>*`	[reply]