(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Symmetry between Attributes and Accessors]
It is proposed that class attributes may be treated as functionally
equivalent to an identically named accessor method. In this manner, it
shall become irrelevant to callers whether a public attribute of an
object is implemented as an attribute, or an lvalue method. Subclasses
may implement either form, at will:
class Bar {
attr $foo is public, Integer; # a value
}
class Zap is Bar {
method foo is Integer is lvalue { ... a calculation ... };
}
...
my $v1 = $my_bar.foo = 5;
my $v2 = $my_zap.foo = 5; # no difference
[Discussion]
Perl6 has identical syntax for accessing methods and attributes. If
this remains the case, than an attribute can be thought of as being
symmetric (from the caller's point of view) with an lvalue-based
accessor:
method foo is Integer is lvalue { ... }
As such, there may be no need for the users of a class to differentiate
between the two.
The usefulness of this approach lies in the ability to extend aspects
of a class that were not originally intended to be dynamic, i.e., to
apply a calculation to an otherwise static attribute, and vice versa.
Note that in languages that differentiate between "$obj.foo" and
$obj.foo()", changing a public attribute to a method clearly violates
the public interface of the class, and can involve search-and-replaces
in large libraries of code.
An alternative approach to this proposal is typically implemented using
explicit accessor methods:
class Bar {
attr $_foo is Integer;
method foo is Integer is lvalue { $._foo };
}
class Zap is Bar {
method foo is Integer is lvalue { ... a calculation ... }
}
This approach is predicated on class Bar being constructed with the
appropriate accessor methods in the first place. The question is,
should the proposed symmetry be introduced to allow better subclassing
of classes that do _not_ follow this recommended practice.
[PROS]
- Allows substantial flexibility in the use of public attributes.
- Similar usage exists in other OO languages, so people are familiar
with the notion.
- perl5 migrants -- used to the notions of objects-as-hashes, and all
attributes being public -- might find this feature comforting.
[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 the behavior.
- An attribute and a method are _not_ typically implemented in the same
manner. Treating the two as interchangeable might imply runtime
overhead.
[Related Issues, Known Implications]
- Proposal: Attributes: "public" vs. "private"
- Proposal: Attributes may contain automatically dereferenced Closures
- Proposal: Use of Attributes within Interfaces
- Whether accessor methods are automatically generated for attributes.
MikeL
