in reply to Re: Seeking inside-out object implementations
in thread Seeking inside-out object implementations
Serialization via Data::Dumper or Storable seems to be the Achilles Heel of all of the inside-out implementations. It seems to me to be a Very Bad Thing(TM) that, by default, including a reference to almost any inside-out object in a larger data structure results in a data structure that cannot be serialized.
I find that assuming that if you "walk the reference recursively, remembering everything you find" you have reliably serialized your object a very shaky way of programming. I'd never, ever make such an assumption for code that was important.
If I have the need to serialize objects, their classes shall have store/retrieve methods, whether they have been implemented with inside-out objects, hash-based objects, or something else. Anything else just stomps all over encapsulation, and results in code that doesn't deserve to be checked into source control.
And, of course, fixing that would require making it possible to break encapsulation via manipulation of the serialized instance - thus defeating the raison d'Ítre of inside-out objects.
No. The point of inside-out objects isn't to prohibit messing with the internals. The point of inside-out objects is two-fold: preventing accidental messing with the internals, and giving you all the benefits of use strict.
I also severely dislike the use of 'lexical globals' inherent in them. It makes anything using them difficult to make completely thread-safe.
I do not know what 'lexical globals' are. And I don't think that inside-out objects are anyway less thread-safe than hash based objects are. (Now, certain modules claiming to do inside-out objects may not be thread safe).