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


in reply to Why is a hash the default "object" in oo perl?

I'll just reply to the question in the title. A hash is preferred because it provides a data structure with named access. A subclass, if you can tolerate the knowledge of the superclass's implementation, can easily add hash elements to the progenitor.

That is impure, as OO goes, but it works awfully well.

After Compline,
Zaxo

  • Comment on Re: Why is a hash the default "object" in oo perl?

Replies are listed 'Best First'.
Re^2: Why is a hash the default "object" in oo perl?
by toma (Vicar) on Jul 18, 2004 at 07:35 UTC
    Inheritance in perl is a cooperative enterprise. Modules need to be designed to allow inheritance. Modules can also be designed to disallow inheritance. I don't know if the implementation has changed since then, but some time ago I had this problem with Bit::Vector.

    I have had trouble figuring out which modules are designed to support inheritance. I end up looking at implementations to try to figure it out.

    The 'hidden implementation' idea of OO isn't a reality in many common perl modules. To me this appears to be a side effect of the TIMTOWTDIness of perl OO.

    When I am evaluating a module implementation with the idea that I might want to inherit from it, my favorite thing to find is a blessed hashref without a fancy OO-helper module. As Zaxo says, it is easy to use and works well.

    It should work perfectly the first time! - toma
      When I am evaluating a module implementation with the idea that I might want to inherit from it, my favorite thing to find is a blessed hashref without a fancy OO-helper module
      Untill you accidentally step on your parents key and break stuff that you'll never, ever track down.
        I have stepped on a key before, but it was easy to find with Data::Dumper.

        Now I am in the habit of writing a little test program using the module. The test program uses Data::Dumper so that I can look at the object before writing something that will inherit from it.

        This approach has been satisfactory unless the objects are overly large, complex, or numerous. There are several dimensions to this scalability problem:

        1. Length: The object is really long, such as Data::Dumper output that is more than 10,000 lines long.
        2. Depth: The data structure has too many levels, so that indentation is hard to follow. I typically start to lose insight somewhere between 5 and 10 levels of depth.
        3. Complexity: Since the hash values come out in a non-intuitive order, small things can get lost next to big things.
        However, if I'm doing something this big and complex I usually have the time to do some research to figure it out.

        My approach is not perfect. This may be why I don't use an IS_A relationship when a HAS_A relationship will probably work just as well in my immediate application.

        It should work perfectly the first time! - toma

        I've used my subclass package name as a key to a child hash. So while my parent may say $self->{ 'key' } internally, I say $self->{ +__PACKAGE__ }{ 'key' } which works as long as my parent doesn't name their hash keys things like Foo::Bar.

        # A "dumping" of such a structure. $self = { bar => ..., foo => ..., 'Foo::Bar' => { bar => ..., foo => ... } }