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] |
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.
| [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] |
