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?

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.