Re^13: Perl OO and accessors

So we have different ideas of what attribute means, fine. I absolutely agree that my conclusion don't hold for your definition of attribute but I don't understand why you think it fails for my definition.

I still maintain that if the attribute behaves exactly like a stored piece of data then you should give it the same interface that we use for every other stored piece of data in the system. I haven't heard a single reason why this is undesirable in principle or an argument why set/get methods provide a superior interface.

Thinking in shell terms, consider the variables like RANDOM, SECONDS, etc. They change out from under you in a similar manner.

They're an example of something that should never have been a variable in the first place. In everything besides shell they are functions. I'd guess the reason they're variables in shell is because there was no other way to do it way back when they were introduced. I can't see any advantage to having them as variables. Can you?

Besides, $o->foo isn't a variable. It's a CODEREF.

It's neither a variable nor a CODEREF, it's a method invocation but that's not important. The point is that using lvalue and tie, it presents the interface of a variable and can be used anywhere that a variable previously might appear. So I can do

$x++;
$o->foo++;
$x=7
$o->foo = 7;
chomp($x);
chomp($o->foo);

sub truncate
{
  my $string = shift;
  if (length($$string) > 10)
  {
    $$string = substr($$string, 0, 10);
  }
}
truncate(\$x);
truncate(\{$o->foo});
[download]

I don't understand your comments about ${$o->foo}. Why should I be comparing that? That brings us back to exposing a part of the object directly plus it's ugly as you point out. The fact that it *would* be a variable is not only irrelevant but actually a disadvantage. I'm not saying that $circle->Area *is* a variable just that it has the exact same interface and behaviour as a variable even though internally $circle actually stores the radius not the area.

Comment on Re^13: Perl OO and accessors Select or Download Code

Replies are listed 'Best First'.
Re^14: Perl OO and accessors by Perl Mouse (Chaplain) on Nov 30, 2005 at 21:13 UTC
I can't see any advantage to having them as variables. Can you? `$ echo "'$RANDOM' is a random number"` [download] `Perl --((8:>*`	[reply] [d/l]
Re^15: Perl OO and accessors by fergal (Chaplain) on Dec 01, 2005 at 00:58 UTC
Is that supposed to be an argument for having them as variables? If Bash had a function named random rather than a variable then you could do this `echo "'$(random)' is a random number"` [download] If the extra ()s are too much of a burden then the logical conclusion is that everything should be a variable just to make it easy to do in string interpolation. The principle of least surprise means that you shouldn't make something look like a variable if it's not going to behave like one. For example `MINUTES=5 echo $MINUTES # 5 SECONDS=5 echo $SECONDS # 1276` [download] How can that be a good thing? There's not even a warning. Also, having variables that aren't leads to run time errors that could have been caught at compile time. If random was a function, attempting to assign to it would be an error (at runtime in bash but at compile time in perl).	[reply] [d/l] [select]