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


in reply to Help understanding object constructors

nisha, I don't like to use a hashed based (or pseudohashes) class.

I strong recommend you another way to write your class, explainned on book Perl Best Practices, named as 'inside-out'. In taht way, you write your class on a closure and get better control over variables acess and methods.

More information about how to write your class on this way, you can look at CPAN Class::Std and Class::Std::Utils.

He a very simple example of your object constructor, and on my opinion better constructors than pseudohashes. For you that are starting on Perl, start on the better way. Learning all way, but do in the best way. 

package MyClass;
use Class::Std;

# Create storage for object attributes...
my %connnectionInfo : ATTR;

# Handle initialization of objects of this class...
sub BUILD {
  my ($self, $obj_ID, $arg_ref) = @_;

  $connnectionInfo{$obj_ID} = $arg_ref;
}

[download]
Solli Moreira Honorio
Sao Paulo - Brazil
  • Comment on Re: Help understanding object constructors (by Perl Best Practices book)
  • Download Code

Replies are listed 'Best First'.
Re^2: Help understanding object constructors (by Perl Best Practices book)
by dragonchild (Archbishop) on Nov 07, 2005 at 14:43 UTC
    I --'ed your node because it was completely off-topic. The confusion was hash-references vs. loops, not OO constructors. As the OP was confused about basic syntax, bringing up inside-out objects was a bit too much.

    Furthermore, inside-out objects is most certainly not the "best way". In fact, many top Perl programmers choose to NOT use Inside-out objects, for a variety of reasons. These would include:

    1. They don't play nicely with Data::Dumper or Storable
    2. They can have memory leaks (even Class::Std can under pathological circumstances)
    3. They are about 10x slower than hash- or array-based objects under average use
    4. Extending the class on the fly is unintuitive
    5. Subclassing can still have bad situations (method-based vs. hashkey-based)

    They are nice, but they're not the cure for cancer.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      They are about 10x slower than hash- or array-based objects under average use

      Agree with everything apart from this one, which doesn't match my experiences at all.

      My inside out classes are within a gnat's whisker of being as fast as plain hash-based objects wherever I've used them, and the slowest inside-out object framework that I've come across (Class::Std) is only a bit over twice as slow when I've benchmarked it.

[reply]
      1. They don’t play nicely with Data::Dumper or Storable

      That merely requires that someone write STORABLE_freeze and STORABLE_thaw methods for inside-out objects, and that they make use of Data::Dumper’s Freezer/Toaster stuff (which, unfortunately, is not as automatic as Storable’s hooks are).

      None of the problems are insurmountable.

      Inside-out objects are not the cure for cancer, but they sure help with gray hairs.

      Makeshifts last the longest.

[reply]
      They don't play nicely with Data::Dumper or Storable
      Yeah, but is that a bad thing? 'Data::Dumper' and 'Storable' only work by making assumptions on how objects are implemented - they assume the entire state can be captured by capturing the content of the referent. Which, in many OO circles, is seen as very bad programming. Not playing nice with someone who isn't playing nice isn't necessarely bad IMO.
      They can have memory leaks (even Class::Std can under pathological circumstances)
      What circumstances are those?
      They are about 10x slower than hash- or array-based objects under average use
      Do you have a benchmark? I'm not at all interested in the numbers - what I'd like to see is what you classify as "average use".
      Extending the class on the fly is unintuitive
      Really? How is extending the class when using inside-out objects any different from non inside-out objects? Or do you mean "I can't get at the data"? That seems to be the point Damian is making in his book, isn't?
      Subclassing can still have bad situations
      What do you mean by that? What is a "bad situation"?
      Perl --((8:>*
[reply]
        Not playing nice isn't necessarily a bad thing. However, it is still a reason why I choose to use hash-based objects in most of my programming. The ability to debug w/DD is a very nice thing indeed.

        Class::Std is, first off, not thread-safe. Second, if I inherit from Class::Std to create my own OO model based on it and I don't call SUPER in the DESTROY, there's a memory leak. (It's pathologically idiotic, but it's there.)

        My benchmark numbers are simple ones from playing with it and what I've seen reported. I will gladly stand corrected given the responses I received.

        As for subclassing, Damian has tried to work around the problems when two attributes are declared with the same name in the same hierarchy. But, that's still a problem. While you and I both know that it's a problem inherent to inheritance and composition in general, people cite inside-out objects as a way of avoiding hashkey clashes (which it is), then conclude that it's a way of avoiding attribute clashes (which it isn't). I was merely making that point explicit.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Seekers of Perl Wisdom