|laziness, impatience, and hubris|
Re: Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)by demerphq (Chancellor)
|on Dec 15, 2002 at 23:39 UTC||Need Help??|
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...