in reply to Trying to understand Perl Objects

In Perl a Class is just a namespace, methods are just subs and object are just references that are blessed into a particular namespace (references to anything really - if you really want to you can build objects by blessing a format-handle),

If you are really interested in Perl-OO I can recommend Damian Conway's book "Object Oriented Perl" which explains all the mechanics and some more advances techniques such as inside-out classes.

I think you should definitely understand the way Perl-OO works in principle and then move on to something like Moose that takes the tedium out of it.

Replies are listed 'Best First'.
Re^2: Trying to understand Perl Objects
by tamaguchi (Pilgrim) on Apr 04, 2009 at 20:11 UTC
    Thank you all for your answers. I understand it now. The problem with having the a complex datastructure is thatthe inormation in it will be more difficoult to access. Yes you can have methods but the methods will be more difficult to write compaired to if the information was in "normal" variables, arrays etc. I also wonder how you do to associate a object to another object? Should the object reference be added to the anonymous hash? How could that be done?
[reply]
      Here an example for association: 

      package Rider;
sub new {
 my($pck, $name)=@_;

 return bless { name => $name }, $pck;
}
      This is a Rider-class with a "name"-attribute, you can create new instances with Rider->new("John Wayne"). Now a horse with a rider: 

      package Horse;
sub new {
 my($pck, $horse_name, $rider_name)=@_;

 return bless { 
               name => $horse_name,
               rider => Rider->new($rider_name),
              }, $pck;
}

      You can create instances with Horse->new("Mr Ed", "John Wayne"). The created class will have a "rider"-attribute which is an instance (= blessed reference) of the rider-class.

      So yes you simply store the object-references in your underlying data-structure.

      And by the way: The reason I bless not directly into "Rider" and "Horse" namespaces but rather use the package-name that the constructor gets passed when called via e.g. Rider->new (you should NOT call it as Rider::new) is so that I can re-use the constructor in a derived class - read Damian's book if this is unclear.

      hth

[reply]
      I also wonder how you do to associate a object to another object? Should the object reference be added to the anonymous hash?

      Not exactly sure what you mean by 'associate', but an object reference can be stored like any other reference (it's just a scalar), e.g. as values in a hash... from where you can then access the object whenever needed.

[reply]
      The problem with having the a complex datastructure is thatthe inormation in it will be more difficoult to access. Yes you can have methods but the methods will be more difficult to write compaired to if the information was in "normal" variables, arrays etc.

      This is strange. The idea being that 20 variables out in the open are somehow easier to deal with than 20 inside a single point of contact (an object). It's within the realm of possibility that the first could be slightly easier to access than the second only if the design is global in nature and that's one of the great evils that objects, class instances, avoid.

      Probably you should step out of the theoretical discussions immediately and try to write some OO Perl to see where and how it goes. Or give a clearly defined, minimal, problem in a new SoPW post to see the kinds of options and approaches the monks can provide for a real problem.

[reply]

In Section Seekers of Perl Wisdom