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.

I can't see any advantage to having them as variables. Can you?

  $ echo "'$RANDOM' is a random number"
[download]

Perl --((8:>*

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).