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

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.