Both these problems can be easily fixed. Just add the C<use strict>
pragma, then pre-declare your package variables. (The C<our> operator
-will be new in 5.006, and will work for package globals just like C<my>
+will be new in 5.6, and will work for package globals just like C<my>
works for scoped lexicals.)
package Some_Class;
use strict;
- our($CData1, $CData2); # our() is new to perl5.006
+ our($CData1, $CData2); # our() is new to perl5.6
sub CData1 {
shift; # XXX: ignore calling class/object
$CData1 = shift if @_;
package Some_Class;
use strict;
- our %ClassData = ( # our() is new to perl5.006
+ our %ClassData = ( # our() is new to perl5.6
CData1 => "",
CData2 => "",
);
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.
use strict;
# create class meta-object using that most perfect of names
- our %Some_Class = ( # our() is new to perl5.006
+ our %Some_Class = ( # our() is new to perl5.6
CData1 => "",
CData2 => "",
);
package Some_Class;
use strict;
- our %Some_Class = ( # our() is new to perl5.006
+ our %Some_Class = ( # our() is new to perl5.6
CData1 => "",
CData2 => "",
);
haven't thought of before.
package Some_Class;
- our($CData1, $CData2); # our() is new to perl5.006
+ our($CData1, $CData2); # our() is new to perl5.6
sub new {
my $obclass = shift;
package Some_Class;
use strict;
- our %Some_Class = ( # our() is new to perl5.006
+ our %Some_Class = ( # our() is new to perl5.6
CData1 => "",
CData2 => "",
);
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
variables, user and group IDs, or the current working directory are
treated across a fork(). You can change only yourself, but you will see
those changes reflected in your unspawned children. Changes to one object
-will propagate enither up to the parent nor down to any existing child objects.
+will propagate neither up to the parent nor down to any existing child objects.
Those objects made later, however, will see the changes.
If you have an object with an actual attribute value, and you want to
# so the latter can be used for both initialization
# and translucency.
- our %Vermin = ( # our() is new to perl5.006
+ our %Vermin = ( # our() is new to perl5.6
PopCount => 0, # capital for class attributes
color => "beige", # small for instance attributes
);
No one--absolutely no one--is allowed to read or write the class
attributes without the mediation of the managing accessor method, since
only that method has access to the lexical variable it's managing.
-This use of mediated access to class attributes is a form privacy far
+This use of mediated access to class attributes is a form of privacy far
stronger than most OO languages provide.
The repetition of code used to create per-datum accessor methods chafes
=head2 Translucency Revisited
-The Vermin class used to demonstrate translucency used an eponymously
-named package variable, %Vermin, as its meta-object. If you prefer to
+The Vermin class demonstrates translucency using a package variable,
+eponymously named %Vermin, as its meta-object. If you prefer to
use absolutely no package variables beyond those necessary to appease
inheritance or possibly the Exporter, this strategy is closed to you.
That's too bad, because translucent attributes are an appealing
We use the hypothetical our() syntax for package variables. It works
like C<use vars>, but looks like my(). It should be in this summer's
-major release (5.006) of perl--we hope.
+major release (5.6) of perl--we hope.
You can't use file-scoped lexicals in conjunction with the SelfLoader
or the AutoLoader, because they alter the lexical scope in which the
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