in reply to Re^4: Method Chaining and Accessors
in thread Method Chaining and Accessors

I suggest that your carping still counts as a surprise and Personally, I think that get_foo is the cleaner of the two, but whatever floats your boat (or the boat of the person that writes your coding standards)

Since $self->{attribute} is wrong it should look wrong. If it doesn't stand out as being, people may not spot it, or worse still, end up "fixing" the $self->get_attribute;

And as for "Not if you don't have any mutators, they don't.". It gets a little tricky when you use someone else's cpan module that still uses mutators? *bam* you've got your getters, and their mutators, and there's arms legs and butts in all sorts of disorder!

As an interesting development, kyle has just the thing to allow you to port to an insideout object system at Make an inside-out object look hash-based using overload.

@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

Replies are listed 'Best First'.
Re^6: Method Chaining and Accessors
by doom (Deacon) on Apr 12, 2007 at 16:14 UTC
    Personally, I think that get_foo is the cleaner of the two,
    You have an odd notion of what's "clean", though of course you do have a point that any change in standard practice has potential to cause confusion.

    The thing with me is I can't remember any case where I've just guessed what accessor I should be using, because there isn't any way to intuit the name of the attribute itself -- it always comes out of the documentation, half of the time it comes straight out of the SYNOPSIS.

    Since $self->{attribute} is wrong it should look wrong.
    Well, different things should look different, right? Which is why I think "get_*" and "set_*" methods look too similar.

[reply]

      ... At this point i'm not sure if i'm repeating myself or not ...

      q{ You have an odd notion of what's "clean" }. This is true, I learnt perl by reading merlyn's (et al) llama and TheDamian's Perl Best Practices, so I suspect that my view may be a little tainted by what I've been told is "just the right way to do it".

      Yes, you do get stuff from the SYNOPSIS the first time, but after that, you should be able to guess the interface of the module, getters, setters and all should become fairlly obvious to guess after a short period of use.

      q{ Well, different things should look different, right? }. Yes this is true, a constructor should look like one, and a setter method should look like one. Things should look different, but if something is wrong, it should always look wrong. 

      $f00li5h = f00li5h->new();
$f00li5h->{moose};        # looks wrong because my objects never work 
+that way
$f00li5h->get_moose;      # *magic*
$f00li5h->set_moose( 8 ); # *magic*

$doom  = Doom->new();
$doom->get_moose;         # looks wrong - your objects don't work like
+ that
$doom->{moose}            # wrong-o
$doom->moose;             # *joy* this is the ticket
$doom->set_moose( 21 );   # looks right to people who often use doom's
+ objects

      [download]
      I suppose that i've just somewhat countered my own point, but get_* and set_* will always look right on instances of my class, and always look wrong on instances of yours (as long as the instances are named uniformly - ie you don't call an instance of Doom something like $f00li5h)

      I'd say that their looking similar makes for a uniform interface... also: 

      $f00li5h->get_foo;
$f00li5h->set_foo('new value');

      [download]
      don't look too similar due to the argument to set_*

      @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;
[reply]
[d/l]
[select]
        $f00li5h->{moose}; # looks wrong because my objects never work that way
        But... isn't that a "surprise"? Doesn't everyone expect perl objects to work that way? How can you deviate from the standard without creating mass confusion?
[reply]

In Section Seekers of Perl Wisdom