|
in reply to 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. 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.
I also severely dislike the use of 'lexical globals' inherent in them. It makes anything using them difficult to make completely thread-safe.
In the quest for encapsulation enforcement, they may be throwing the baby out with the bathwater.
|
Re^2: Seeking inside-out object implementations
by revdiablo (Prior) on Dec 06, 2005 at 21:27 UTC
|
In the quest for encapsulation enforcement, they may be throwing the baby out with the bathwater
I guess the bathwater is inside-out objects, but what is the baby here? Do you mean an object that can be externally serialized and plays well with threads? Well, to be honest, these seem like pretty specific needs. Granted, the Hard Core Encapsulation you get from inside-out objects may be pretty specialized too, but why is your set of special needs more important than another? I'm not trying to convince you to use IOO, but your argument against it seems kind of hollow in my mind.
| [reply] |
|
|
Most people expect to be able to serialize things with Storable, and many modules like MLDBM or CGI::Session/Apache::Session depend on it. It's not an esoteric concern. Neither is easy debugging with Data::Dumper or the 'x' command in the debugger. Thread use may not be widespread, but serialization is.
| [reply] |
|
|
Most people expect to be able to serialize things
Just to be clear, we are talking about object serialization, right? I would certainly say serialization of data structures is common, but I was talking about objects in specific. That's something I haven't really ever had the need for in Perl. I don't see a whole lot of people asking how to do it, either (either here or in #perl). Because of this, I assumed it wasn't very common. I'm not saying this assumption is correct, of course, just explaining how I arrived at it. I'll just have to suspend judgement for now, I guess.
| [reply] |
|
|
|
|
Howdy!
Perl programmers have come to expect to be able to get at the innards
of objects easily -- that the internals are *not* encapsulated in any
meaningful way. One can fairly argue that that creates a number of
weaknesses and/or potentially fatal problems -- problems that would
exist in some fashion any time an object is not opaque. Consider the
risks one would take by making the attributes of a Jave class public.
Inside-out objects do encapsulate quite fiercely, and are very opaque.
If one needs to serialize an opaque object, that object needs to provide
that capability itself. One might expect a standard mechanism for doing
that. "to_string" might be a suitable method name. I think PBP advocates
creating just such a routine for this purpose.
It sort of comes down to "managing expectations", and, particularly,
changing those expectations.
| [reply] |
Re^2: Seeking inside-out object implementations
by Perl Mouse (Chaplain) on Dec 07, 2005 at 00:10 UTC
|
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).
| [reply] |
Re^2: Seeking inside-out object implementations
by jdhedden (Deacon) on Dec 09, 2005 at 18:03 UTC
|
| [reply] |
|
|
