http://qs321.pair.com?node_id=11116892


in reply to Converting Hashes to Objects

yet another useful module (yaum!)

I often miss Java's standard object methods toString, equals, compareTo, perhaps serialise. But if you do implement these you are building a Class builder I guess. A (more) standardised class builder.

Another thought is to provide a *safe and proper* way to convert from a string representation of a perl data structure(pds) to pds via an object: fromString or deserialise. BUT AGAIN, that's moving away from keeping it all simple and compact and risk offering something that's already out there. The plus point is that you are setting a standard. Which may be against Perl spirit (edit: i mean my suggestions)?

Replies are listed 'Best First'.
Re^2: Converting Hashes to Objects
by haukex (Archbishop) on May 18, 2020 at 12:50 UTC

    Thanks :-)

    I often miss Java's standard object methods toString, equals, compareTo, perhaps serialise.

    The first three would usually be done with overloading, I guess, and serialization depends on the format (like Storable or one of the many text-based formats). I wrote a bit about the complexity of equals and hashCode in this node.

    Another thought is to provide a *safe and proper* way to convert from a string representation of a perl data structure(pds) to pds

    I tried to do something like that with Config::Perl (see Undumping Perl).

[reply]
[d/l]
[select]

      I was thinking that perhaps it would be easier to auto-implement these methods if you have the object as a hash, which is your input in this case.

      My point was that it is an advantageous start you have there when you are given the object as a hash. So, some things, otherwise tedious, could be auto-implemented. For example, equals() a hash or equals() an object are equivalent but the hash can be cleaner and simpler. Sure objects are hashes eventually but you never know what trickery you will find in there. Same with dumping an object versus dumping a hash.

[reply]
[d/l]
[select]
        So, some things, otherwise tedious, could be auto-implemented. For example, equals() a hash or equals() an object are equivalent but the hash can be cleaner and simpler.

        Ah, I see what you mean. Well, I do think that some of the classic issues of comparing data structures still come up. For example, are these two hashes the same?

        my $x = { foo => { bar => "quz" } };
my $y = { foo => { bar => "quz" } };

        [download]

        The answer might appear obvious, but note that $x->{foo} ne $y->{foo}! So I think it's still up to the implementor to decide how to determine whether their objects are the same. For simple recursive data structure comparisons, there's e.g. Data::Compare.

[reply]
[d/l]
[select]

In Section Meditations