in reply to Re^6: Perl OO and accessors
in thread Perl OO and accessors

Ovid's beating a straw man in that quote. Nobody is suggesting that everyday you should bash out lots of awful code directly involving tieing. Would yourself and Ovid also object to exporting values and functions because it involves advanced symbol table poking? Of course not, it's all hidden behind Exporter. Most users don't know how it works at all.

The same goes for lvalue+tie. As I said in another post there's Class::Accessor::Lvalue. Personally I use my own home brew module which lets me say 

package Circle;

use Fergal::MM qw( Radius Area );
# this creates
# setRadius, getRadius, Radius
# setArea, getArea, Area
#
# All are created in Circle::Accessors and Circle's @ISA
# is updated to include Circle::Accessors.
# This makes overriding easy.

# now override the Area ones
sub setArea
{
  my ($self, $area) = @_;
  $self->Radius = sqrt($area/PI);
}

sub getArea
{
  my ($self, $area) = @_;
  my $r = $self->Radius;
  return PI * $r * $r;
}

[download]

This removes all but one of Ovid's complaints - it's probably slow but if you really need speed then you can just ignore the lvalue interface and use the set/get methods directly. I think I benchmarked it as a factor of 10 slower but how much of your code is accessor calls? If you really need speed, Perl OO is probably not what you want.

Replies are listed 'Best First'.
Re^8: Perl OO and accessors
by sauoq (Abbot) on Nov 29, 2005 at 13:48 UTC

    My summary: lots of needless complexity for little or no real gain. I object to that. Strongly. It's not good enough that you can do it. Why would anyone want to? I don't agree, by the way, that what you've shown removes "all but one of Ovid's complaints" but say we take that to be the case. What about the remaining issue? Why would I want to leave bits of a redundant API around with the caveat that, if performance is an issue, they shouldn't be used?

    -sauoq
"My two cents aren't worth a dime.";
[reply]
      lots of needless complexity for little or no real gain.

      First off, this is only needlessly difficult in Perl. Python, Ruby and many others support this kind of smart attribute out of the box.

      As for the gain, it's in programmer time, readability, simplicity, conciseness and uniformity.

      An attribute is essentially a variable with possibly some runtime enforced restrictions so it should be accessible just like any other variable. I can do 

      $radius *= 2;
$h{radius} *= 2;
$radii[5] *= 2;

      [download]
      so why should I have to do 
      $c->setRadius($c->getRadius * 2);

      [download]
      why not 
      $c->Radius *= 2;

      [download]
      ?

      The existence of something that fundamentally is a variable but that must be accessed in an unnatural way is actually a source of extra complexity. Accessors and mutators are something that are only necessary when the language designer didn't bother include smart attributes.

      A variable hidden behind methods causes more code to be written by anyone trying to use that variable and it actually prevents code reuse. For example any function which takes a reference to a variable and alters it can not be resued if the interface for the variable is via an accessor method. Whereas an lvalue attribute will work just fine anywhere a normal variable would have worked.

      Occam's razor says we should reduce the number of concepts we have to deal with, lvalue accessors mean we can throw away the awkward not-quite-a-variable attributes. Lispers realised this long ago and introduced generalised variables which give a uniform interface to "cars and cdrs of lists, elements of arrays, properties of symbols, and many other locations are also places where Lisp values are stored".

      Why would I want to leave bits of a redundant API around with the caveat that, if performance is an issue, they shouldn't be used?

      I think this is backwards. The Area method is the primary and recommended interface. setArea and getArea are the redundant parts of the interface (although they are an essential part of the implementation) and are available in case performance is an issue (they might also be useful if other code is expecting a setter method rather than an lvalue).

      So essentially, while the implementation may be complex, it is once-off complexity, hidden even from the author of the class and results in an overall reduction of complexity and increase in productivity. If it leads to unacceptable performance issues you can choose to use to the use the more complex interface in performance sensitive places in which case you still better off than when you were using set/get everywhere.

[reply]
[d/l]
[select]
        Howdy!

        An attribute is essentially a variable with possibly some runtime enforced restrictions so it should be accessible just like any other variable.

        That is needlessly restrictive, and the conclusion does not follow from the premise. Suppose you have a timer that is counting up/down. You may have, as an "attribute", the elapsed time/time remaining. Should that look like a variable? Or should I call a function to retrieve that data? Suppose the data isn't actually stored in the object, but is an external resource?

        Yes, it can be aestheticly pleasing to be able to write code that avoids overt function calls, but the flip side is that you then have derived attributes that look different from innate attributes, or you have to maintain the derived attributes in sync with changes to the innate attributes, further confusing the matter. I take it to be somewhere between "better" and "no worse" to have to make explicit method calls to set/get attribute-like properties of an object.

        yours,
        Michael
[reply]
        First off, this is only needlessly difficult in Perl. Python, Ruby and many others support this kind of smart attribute out of the box.

        Well, since this isn't Python or Ruby, we can safely ignore them I think. As for it being "needlessly difficult", well, in my opinion it's just plain needless. When in Rome, do as the Romans. When coding Perl, do it with a method call.

        I dispute the notion that doing so would lose programmer time, readability, or simplicity. I don't believe conciseness is a goal in and of itself, but if it is, Perl excels at it in other areas, so you've still got an overall win (by far.) And, as with most things in Perl, uniformity is simply up to the programmer. He must do things in a uniform manner because the language doesn't enforce it.

        -sauoq
"My two cents aren't worth a dime.";
[reply]

In Section Meditations