(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: Attributes: "public" vs. "private"]
It is proposed that attributes are considered by default to be
"private" to a class, but may optionally be made "public" on an
attribute-by-attribute basis.
Definition: "public":
A "public" attribute is an attribute which may be accessed
without restriction both inside and outside the class.
Definition: "private":
A "private" attribute is an attribute whose scope is restricted such
that
it may be accessed only within the class in which it has been declared.
It is not available to subclasses, nor to code outside the class.
[But see an alternative possible definition, below]
Example:
class Zap {
attr $foo; # private, by default
attr $foo2 is private; # explicitly private
attr $bar is public; # explicitly public
method meth1 { $.foo } # allowed
method meth2 { $.bar } # allowed
}
class Zot is Zap {
method meth1 { $.foo } # NOT ALLOWED, private to Zap
method meth2 { $.bar } # allowed, is public
}
$my_zot.foo; # NOT ALLOWED, private to Zap
$my_zot.bar; # allowed
[Discussion]
Attributes are typically considered to be private variables for use by
the class (or more precisely, by each separate instance of the class.)
They cannot be accessed outside the class; to do so would violate the
oft-referenced principles of "encapsulation" intrinsic to most OO
methodologies.
Note that an alternate definition of "private" is often used, as
follows:
A "private" attribute is an attribute whose scope is restricted such
that
it may be accessed only within the class in which it has been declared,
OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS.
Many programmers in fact expect "private" attributes to work this way.
Some languages recognize all three definitions, calling the above
"protected" access.
The notion of "public" attributes is controversial within the OO world.
In general, public attributes may be better implemented as public
accessor methods to an attribute that remains private. (It typically
depends on how the language in question uses "attributes", and whether
the language treats attributes and methods in a roughly symmetric
fashion.)
Under the principle of TMTOWTDI, perl allows public attributes within a
class. However, you must explicitly declare an attribute to be public.
[PROS]
- Allows substantial flexibility in the use of class attributes.
- Similar usage exists in other OO languages, so people are familiar
with the notions.
- perl5 migrants -- used to the notions of objects-as-hashes, and all
attributes being public -- might find the ability to declare "public"
attributes 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 this behavior.
- 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".
[Related Issues, Known Implications]
- Proposal: Declaring Class Attributes
- Proposal: Symmetry between Attributes and Accessors
- Proposal: Attributes may contain automatically dereferenced Closures
- Proposal: Use of Attributes within Interfaces
- Whether accessor methods are automatically generated for attributes.
MikeL
