On Wed, Sep 17, 2008 at 01:00:07PM +0200, Carl Mäsak wrote:
: Jonathan (>):
: > Why not just assign to $!foo, which is always read/write (since the rw
: > affects whether you get an accessor that is read/write or not - $!foo refers
: > to the underlying storage location; at least, that's how I understand it and
: > what I think Rakudo is implementing today).
:
: I have come to understand that this is an available possibility, yes.
: That doesn't mean I like it. :)
:
: My complaint could be pithily summarized as "those are _my_,
: attributes, why can't I write to them?"
You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way. We take
similar 3rd-person viewpoints in natural language too, especially
when talking to kids:
Daddy thinks that's okay, but Amy will have to go ask Mommy too.
In C++ish OO terms, $.foo is always virtual, and $!foo is never
virtual. The "has" declarator can intuit from a virtual $.foo
declaration that you also need private non-virtual $!foo storage,
but it can't intuit from a non-virtual declaration that you want to
have a public accessor, at least, not without more information than
the sigil provides, which would be uglier.
So $.foo basically says that you want to talk about the slot from
the viewpoint of the actual object, while $!foo says you want to talk
about the slot from the viewpoint of your class. This is orthogonal
to the actual class boundary, if you ignore the fact that we prohibit
$!foo access from outside the class. (And, in fact, we could probably
still get at it with a private method from outside the class if there
is an appropriate "trusts" declaration.)
Larry
