Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^3: Seeking inside-out object implementations

by perrin (Chancellor)
on Dec 06, 2005 at 21:44 UTC ( #514647=note: print w/replies, xml ) Need Help??

in reply to Re^2: Seeking inside-out object implementations
in thread Seeking inside-out object implementations

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.
  • Comment on Re^3: Seeking inside-out object implementations

Replies are listed 'Best First'.
Re^4: Seeking inside-out object implementations
by revdiablo (Prior) on Dec 07, 2005 at 00:24 UTC
    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.

      I may see this more than most because it comes up frequently on the mod_perl and Class::DBI lists, but yes, people expect to be able to serialize objects. Every caching system for Perl uses Storable, and people expect to cache objects. Same for sessions.
Re^4: Seeking inside-out object implementations
by herveus (Parson) on Dec 08, 2005 at 15:57 UTC

    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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://514647]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2018-05-20 20:41 GMT
Find Nodes?
    Voting Booth?