This all looks good to me. I seem to have gone off on a tangent about
slots, so I've mercifally changed the subject.
On Fri, Oct 04, 2002 at 04:39:40PM -0700, Michael Lazzaro wrote:
> [CONS]
>
> - Making publicly accessible attributes at all is considered Bad Form
> in most OO methodologies (which advocate the use of explicit accessor
> methods.) We may wish to discourage or even prohibit this behavior.
I believe that since we're going with the notion of "slots" (to use
the term from Self) this problem goes away. Though I think I'm
getting ahead of things.
In the spirit of the thing, I'll define what I mean by "slot".
A style of OO syntax in which an attribute access and a method call
are syntactically indistinguishable.
Another way to look at it...
Every attribute comes with a default accessor/mutator method which
is the only way to access that attribute. Private attributes have
private accessors, public are public.
Here's an example.
class Foo {
attr this; # private by default
attr that is public;
attr thing;
method foo is private {
# the two are indistinguishable
.bar('something'); # method call
.this('wiffle'); # set the 'this' attribute
}
method bar ($arg) {
...
}
}
my $obj = Foo.new;
$obj.that('wibble'); # perfectly ok. The caller does not know
# they're "directly" accessing an attribute
(I've explicitly avoided the issue of lvalue method calls. That's a
whole 'nother subject. If they're in Perl 6, they'll definately be
applied to the above)
Slots, by making method calls and attribute accesses indistinguishable
to the user, effectively wrap every attribute in an accessor method.
So, in a sense, you're just using accessor methods but you just don't
have to go through all the trouble of writing it all out.
Slots merely exploit the fact that while a public attribute is
considered bad, a private attribute accessed via a public accessor
method is fine. So slots simply make all public attributes the moral
equivalent of a private attribute with a public accessor.
Furthermore, slots promote extendability like normal accessors in that
the default behavior can be overriden by simply defining a method with
the same name as the attribute.
I believe Damian has sketched out something like this using attribute
properties but with some flexiiblity in how the default accessors
behave like "is readonly" or "is readwrite".
Details aside, if you make attribute and method access
indistinguishable, the problem of public attributes goes away.
> - Using the alternative definition of "private" (e.g., "protected")
> given above may be what many programmers expect, and may be more in
> line with perl's philosophy. It seems especially wonky to allow the
> cootie-infested "public" but not allow the more liberal interpretation
> of "private".
This sounds like "two wrongs make a right" to me.
--
Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
