Help understanding object constructors

[nisha]

Hi Perl Monks, I have this loop below in one of the programs that i was trying to analyse, could you please explain to me what this means.

sub new 
{
    my $type = shift;
    my %parm = @_;
    my $this = 
    {
        _server => undef,
        _database => undef,
        _hSession => undef,
        _hDatabase => undef,
    };
    bless $this, $type;    
}

especially the on in the my $this loop. What are the variables in this loop mean? Please help!

2005-11-07 Retitled by g0n, as per Monastery guidelines
Original title: 'Explanation'

[davidrw]

$this is being assigned the value of a hashref (see perlref), and is NOT a loop. It is the same as doing:

my %thisHash = (
        _server => undef,
        _database => undef,
        _hSession => undef,
        _hDatabase => undef,
);
my $this = \%thisHash;

In both cases (yours and the above), the "variables in this loop" (again, note it is not a loop) are the default key-value pairs of the hash (see perldata).

As for the method sub new { ... } and the bless $this, $type, this is a example of a common way to write a constructor method for an object. For more information, start with perlobj and also there is a specifical Object-Oriented Perl section in the Tutorials here on pm.

[jbrugger]

Correct.
But for standards (and to make it a bit more readable), it might be better to write it like this, although it's also a matter of taste :)


sub new {
    my $classname = shift;
    my %arg= ( _server     => undef,
               _database   => undef,
               _hSession   => undef,
               _hDatabase} => undef,
               @_,
             );
    my $self = {};  # note this corresponds whith $this in your code.
    bless $self, $classname;
    
    $self->{_server}    = $arg{_server};    
    $self->{_database}  = $arg{_database};
    $self->{_hSession}  = $arg{_hSession};
    $self->{_hDatabase} = $arg{_hDatabase};

    return $self;
}

[nisha]

Thank U very much

[pg]

That was not a loop, but a hash reference.

This sub is the constructor of a class, which most likely wraps a database session (or could be a web session). The hash ref stores the attributes of the object. It contains a set of information enough to identify the session, indicating which connection to which database resides on which server etc. Those attributes are initialized to undef to begin with.

[shonorio]

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;
}

[dragonchild]

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.

[adrianh]

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.

[Aristotle]

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.

[Perl Mouse]

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"?