in reply to Object Oriented Perl - very basic guide

A nifty little trick I like to use is to pull @_ directly into the "new" object. This works nicely when @_ contains a hashref.

Example: 

#!/usr/bin/perl
use warnings;
use strict;
my $object = MyObject->new( name => 'MyNewObject', debug => 1 );

print "MyObject Name: $object->{name}\n";
print "Debug setting: $object->{debug}\n";

package MyObject;
sub new {  
  print "method 'new' called with parameters: ", join ("\n", @_ ), "\n
+";  
  my $class = shift
  my $self = {@_};  
  $self -> {state} = "newly created";  
  bless $self, $class;  
  return $self;  
}

[download]
Doing it this way allows you to assign attributes (variables) to the new object when it is created/instantiated.

Another cool feature of perl objects is that you don't need to explicitly define "getters" and "setters", since all they really do is get or set an attribute value. You can accomplish the same thing by getting or setting the attribute value directly (like you would with any other hashref) 

$object->{attribute} = 'value'; #setter
print "$object->{attribute}\n";  #getter

[download]

Replies are listed 'Best First'.
Re^2: Object Oriented Perl - very basic guide
by choroba (Cardinal) on Jun 30, 2014 at 08:39 UTC
    Some hackers don't see it as an advantage. It doesn't catch typos in the constructor attributes: 
    my $obj = 'MyObject'->new( name => 'Typoed', debyg => 1 );

    [download]

    Also, the main point of getters and setters is encapsulation. Directly accessing the attributes breaks it. If you later decide to change the implementation, you need to change the code that touches the attributes as well.

    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]
[d/l]

      I've also had the discussion about whether you should have separate 'set' and 'get' methods, or whether having a single one is 'ok'. E.g. 

      my $status_code = $object -> status;
$object -> status ( "new_status" );

      [download]

      I'm of the opinion that separating them out is good - static attributes you might think you can update in this way, because the paradigm of method calls is the same - as the method call you expect already exists, then it's only at run time you'll find that it doesn't allow changing, where if 'set_state' isn't present it's a bit more obvious.

[reply]
[d/l]
Re^2: Object Oriented Perl - very basic guide
by Preceptor (Deacon) on Jun 30, 2014 at 13:46 UTC

    I'm afraid I wouldn't call that a feature - more like a bug. The whole reason to use OO in the first place is to allow encapsulation - such that you publish methods and handle what those methods actually do internally.

    That's what allows me to write a module, you to use it, and then me to bug fix, tweak, extend without breaking your code.

    It's something that does no harm at first, but promotes bad programming practice and burns you later - something perl is notorious for.

    I've seen a suggestion that basically involves trying to enforce this, via building your object around an anonymous hashref. Because messing with attributes directly breaks first time someone does it, they don't do it a second time.

    I feel largely the same about pulling in vague stuff via @_ or building an object off a hashref. It's not that it doesn't work (and in many ways, this is the biggest fault of perl - that things that _shouldn't_ work, usually do). But that you can build in some really horrific bugs and gotchas by doing it.

[reply]
      I absolutely agree with everyone else here. I wouldn't recommend leveraging the features/bugs that allow you to do something that technically isn't the correct Object Oriented approach for a large project, or something that you are planning to release into the wild (CPAN).

      And yes, just because you can do it that way (as with a lot of things in perl), doesn't mean you should do it that way.

[reply]

In Section Meditations