we have much better approaches, like nested hashes or hashes of arrays.
But there's nothing wrong with using symbolic references to manipulate
something that is meaningful only from the perspective of the package
-symbol symbol table, like method names or package variables. In other
+symbol table, like method names or package variables. In other
words, when you want to refer to the symbol table, use symbol references.
Clustering all the class attributes in one place has several advantages.
particular object. The class's eponymous hash can also be used to
implement I<translucent attributes>. A translucent attribute is one
that has a class-wide default. Each object can set its own value for the
-attribute, in which case C<$object-E<gt>attribute()> returns that value.
-But if no value has been set, then C<$object-E<gt>attribute()> returns
+attribute, in which case C<< $object->attribute() >> returns that value.
+But if no value has been set, then C<< $object->attribute() >> returns
the class-wide default.
We'll apply something of a copy-on-write approach to these translucent
module's methods wind up getting compiled.
The usual mealy-mouthed package-mungeing doubtless applies to setting
-up names of object attributes. For example, C<$self-E<gt>{ObData1}>
-should probably be C<$self-E<gt>{ __PACKAGE__ . "_ObData1" }>, but that
+up names of object attributes. For example, C<< $self->{ObData1} >>
+should probably be C<< $self->{ __PACKAGE__ . "_ObData1" } >>, but that
would just confuse the examples.
=head1 SEE ALSO