Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)

by demerphq (Chancellor)
on Dec 15, 2002 at 23:39 UTC ( #220077=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)
in thread Yet Another Perl Object Model (Inside Out Objects)

but it struck me that serialising objects from the outside is actually a rather strange requirement, and can only be done in perl because of the peculiar nature (relatively speaking) of the way OO is implemented in perl.

Well I dont think its that weird. After all, dumping core is a form of serialization, and that is hardly an unusal activity on a computer. :-) Also many debuggers (im thinking the VB and VC debuggers, and ive seen many open source tools that do similar things) have the ability to show allocated structures in a visual way. So this task is not an uncommon one.

However that aside I will grant to you that being able to dump data in such a straight forward way is a by product of both perls approach to variables and to OO.

But I hardly think its a bad thing. For instance, assuming that a number of the more subtle problems in things like Data::Dumper and friends are either not an issue or resolved, dumping provides a simple portable way to inspect data structures iregardless of their origin. Also the use of the language itself to represent its data, while admitedly a potential security risk, has many advantages. It allows minimal understanding to read for the programmer, in fact it may even be enlightening in terms of understanding perls syntax to read the output of a Dumper, it means that no special tools are required to regenerate the object, and it means the generated file is as platform independent as perl is itself. Furthermore it can be used to facilitate code generators, which is a common design approach.

Compare all this against objects serializing themselves on request. Lets say I throw together a composite data structure like a treap. Now im finished my implementation of the data structure and someone asks me to find a way to save the generated structure. In this case I have to write a whole bunch more code to both read and write it from disk. If I make an error in my implementation, (and as a beginner I just might do that), then things dont work out so well. Sure there are work arounds in other languages where Perls approach doesnt work but I'm guessing they arent as straight forward to implement and are subject to higher levels of programmer error.

Ultimately I think that Dumper is one of Perls many form of Introspection. And in my experience the more intorspection available the easier my life as a programmer becomes. Especially when things start getting weird...

--- demerphq
my friends call me, usually because I'm late....

  • Comment on Re: Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)
by BrowserUk (Pope) on Dec 16, 2002 at 00:53 UTC

    I have no problem with the idea of dumping state as a means of debugging.

    I also have no problem with the idea of dumping structure as a mechanism for learning, reference, or debugging.

    Where it all goes wrong (for me) is the idea of using dumping as a mechanism for saving and restoring state, which is where I would argue that "dumping" transitions to "serialisation". This is doubley bad (IMO) if the form that the serialisation takes is that of generating evalable entities.

    To me, the purposes of serialisation (as opposed to dumping) are twofold--persistance & Interchange.

    The problems I see with doing either of these from the outside of the objects are.

    1. Persistance.

      If an object is in anything other than a simple one level , non-composite (either through is-a or has-a), then storing a complete object with all it's superclass attributes and those of any instances of objects that it has as attributes is illogical.

      If I extend an existing class to add some new attributes, when I come to Persist that new class, I don't want to have to modify the existing stored instances nor modify existing applications that use those instances.

      Assuming a RDBMS is used for storage, better to create a new table for the new attributes and have a foriegn key on the existing table, then create a view to join the two tables for use by the new class, than have to modify the existing table. If I ask the object to persist itself and it calls superclass to persist itself. The superclass instance saves itself in its original table and returns is Primary key ID. Then the subclass instance saves its attributes including the returned key(s) in its own table and the job is done.

      If I attempt this from the outside, then the I get one almighty morass of mixed up data and either need to store it as a single entity, which doesn't make sense if there is any chance of two subclass instance sharing a superclass instance. Or I need to parse the returned monolith to seperate out the parts.

      Add in to this the idea that two Employee instances may share the same Address, or two Urls the same IP etc.

    2. Interchange.

      Even interchangeing evalable datastructures between two Perl applications or sites can be fraught with problems. Whilst Storable can nFreeze to and thaw through network ordering, if the source is 64-bit and the destination 32-bit...?

      Or if one site is dependant upon a downlevel verson of perl that doesn't understand something generated by a newer level.

      As soon as you need to interchange the data between different languages, evalable serialisation makes no sense at all. Better again to have the objects themselves produce a standardized interchange format. The obvious one these days is XML. Each object knows it's own structure and can easily produce this. Superclasses just embed the returned XML from the subclasses into their own representation. Receiving application can simply ignore those attributes it is not interested in.

    That's why I think that serialisation should be done from the inside not externally. Once an instance has that ability, dumping can simply use this. I'd rather read an XML representation of a deeeply nested structure than the output from Data::Dumper I think.

    From the pure dumpability point of view, I actually think that Abigail's version of IO objects is better than the standard hash model in as much as I can build in a class method that dumps the entire class' instances and if the class is subclassed two or more times, the bless'd ref keys in the attribute hashes tell me which superclass was involved in the creation of each instance, which I already found useful as a debugging aid.

    Again this requires adding to and invoking from the class, but I think that it is a small price to pay in terms of development of reusable code.

    Examine what is said, not who speaks.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2017-02-28 18:26 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (407 votes). Check out past polls.