Because lvalue subs are poorly implemented in Perl, they do not in any way allow for hooks to be added in and they essentially expose the underlying data object as well as its type, which pretty much breaks encapsulation (if I know I can ++ on the lvalue sub, then I know that the underlying value *must* be a number, if I want to change that implementation detail, too bad, my class consumers will break).In C++, if I refer to a field, I can't readily make that get/set or in-place modification do something else. It doesn't have "properties" ala C# and other Microsoft languages. Accessing a data member is syntactically distinct from calling a function in every way, since functions must have parens even if there are no parameters.
So, I'm used to that. I refer to data members directly only when they are private implementation detail, and use accessors for public API.
It is mitigated somewhat because names are checked at compile time, so if I had to upgrade a bare field to something hiding behind an accessor, I could remove the field and be sure that all uses were noticed before I ran anything.
Basically you make the same point as browserUK. The reason lvalue accessors are not used is because it doesn't hook setting to perform type checks, coersions, and whatever other hooks.
You covered a lot of ground in your post, so I'll reply to different parts separately or perhaps even start new threads.
In reply to Re^2: Some thoughts on Moose Attributes
by John M. Dlugosz
in thread Some thoughts on Moose Attributes
by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |