I think is some confusion arising form our differing ideas of "attribute".

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?

You changed the premise (widened the meaning of "attribute") it's no surprise that the conclusion no longer follows.

A timer shouldn't look like a variable because it doesn't behave like a variable. Trying to put a variable-like interface on something that doesn't behave like a variable is just confusing and a bad idea and I never suggested that.

My definition was needfully restrictive - in order to reach my conclusion. If your idea of an attribute includes things that don't behave like variables then please run

perl -pe 's/(attribute)/behaves-like-a-variable-$1/g
[download]

Howdy!

It's not that I "changed" your premise so much as I disagree with your premise (and, implicitly, the conclusions you draw from it).

In the context of OO and objects, I take "attribute" to refer to data contained within an object. Quite often, it is a simple variable-like thingy, but it is not necessary that fetching the value of an attribute be idempotent. If an object has behavior, and that behavior is autonomous, then my scenario does hold.

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

Besides, $o->foo isn't a variable. It's a CODEREF. If it's an lvalued CODEREF, then it can masquerade as a variable, and that can be useful, or could be if lvalue subs weren't so limited in what they can do (not to mention making it impossible to use the debugger). ${$o->foo} *would* be and look like a variable, but then you have those extra curly braces cluttering things up. *That's* what you should be comparing, and I find the aesthetics unfavorable.

yours,
Michael

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.