returned by the &bigbang "constructor" is not a reference to a blessed
object at all. It's just the class's own name. A class name is, for
virtually all intents and purposes, a perfectly acceptable object.
-It has state, behavior, and identify, the three crucial components
+It has state, behavior, and identity, the three crucial components
of an object system. It even manifests inheritance, polymorphism,
and encapsulation. And what more can you ask of an object?
print $obj3->color(); # prints "vermilion"
Each of these objects' colors is now "vermilion", because that's the
-meta-object's value that attribute, and these objects do not have
+meta-object's value for that attribute, and these objects do not have
individual color values set.
Changing the attribute on one object has no effect on other objects
# invoked as class method or object method
sub has_attribute {
my($self, $attr) = @_;
- my $class = ref $self if $self;
+ my $class = ref($self) || $self;
return exists $class->{$attr};
}
It is widely perceived, and indeed has often been written, that Perl
provides no data hiding, that it affords the class designer no privacy
-nor isolation, merely a rag-tag assortment of weak and unenforcible
+nor isolation, merely a rag-tag assortment of weak and unenforceable
social conventions instead. This perception is demonstrably false and
easily disproven. In the next section, we show how to implement forms
of privacy that are far stronger than those provided in nearly any
if (my $coderef = $self->can($parent . "::CData1")) {
$self->$coderef($newvalue);
}
- }
+ }
+
+If you override C<UNIVERSAL::can> in your own classes, be sure to return the
+reference appropriately.
=head2 Locking the Door and Throwing Away the Key
properly designed accessor methods is probably not a good idea after all.
Restricting access to class attributes from the class itself is usually
-not enforcible even in strongly object-oriented languages. But in Perl,
+not enforceable even in strongly object-oriented languages. But in Perl,
you can.
Here's one way:
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
+The usual mealy-mouthed package-munging doubtless applies to setting
up names of object attributes. For example, C<< $self->{ObData1} >>
should probably be C<< $self->{ __PACKAGE__ . "_ObData1" } >>, but that
would just confuse the examples.