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