note
adrianh
<p>[Abigail-II] will be better able to comment than myself, but I've been playing around with her
technique on-and-off since I [id://178518|discovered it on perlmonks]. While I've not been doing it in anger, it's not been entirely in jest either. I've been re-writing some [cpan://Test::Class] hierarchies that were fairly deep, and hence possible sources for hash key clashes.</p>
<p>In general I've not had problems. It's a <em>very</em> nice hack to get around perl's lack of object attribute encapsulation. I'll probably use the technique in the next production project I do.</p>
<p>[Abigail-II] - have you considered writing a little tutorial on the subject? :-)</p>
<p>Issues that can cause problems:</p>
<ul>
<li>
<p>You have to take overloading the "" operator into account. Since the attribute objects are indexed by "$self", you have to use <code>overload::StrVal</code> something like this:</p>
<code>
package Foo;
use strict;
use warnings;
use overload;
my %foo = ();
sub new {
my $class = shift;
bless [], $class;
};
sub foo {
my $self = overload::StrVal shift;
$foo{$self} = @_ if @_;
$foo{$self};
};
sub DESTROY {
my $self = overload::StrVal shift;
delete $foo{$self};
};
</code>
<p>if there is any chance that somebody will write a sub-class that overrides "", for example:</p>
<code>
package Foo::Pretty;
use base qw(Foo);
use overload
q{""} => sub {
my $self = shift;
my $foo = defined($self->foo) ? $self->foo : 'undef';
"<foo=$foo>";
},
;
</code>
</li>
<li>
<p>Having to remember to add/remove attribute hashes from the <code>DESTROY</code> method can be a pain. I tend to move attributes around classes a fair bit during refactoring. Forget to add an appropriate <code>delete</code> line to the <code>DESTROY</code> method and you suddenly have a nasty little memory leak. I've had this happen to me more often in the few weeks I've been playing with this technique than I've had hash/method name clashes in the several years I've been writing OO perl - but that may be lack of practice :-)</p>
</li>
<li>
<p>Object serialisation and other reflective acts become harder. No more quick'n'dirty throwing your object at [cpan://Storable] to serialise your object. No more throwing your object at [cpan://Data::Dumper] to get a snapshot of its state. This could be considered a feature depending on your point of view.</p>
</li>
<li>
<p>I've not had the chance to try teaching this method to perl/OO novices. My hunch is that it will turn out harder than hashes. Perl novices are already used to stuffing stuff in hashes, so it's a natural progression. OO novices latch onto the idea that an object is a "thing". My guess is that a single "thing" spread over several hashes goes against the naive concept of what an object is, and will therefore be harder to teach.<p>
</li>
<li><p>
Having to list all of the attributes in the <code>DESTROY</code> method, as well as declare them at the top offends my sense of [http://c2.com/cgi/wiki?OnceAndOnlyOnce|once and only once].
</p></li>
</ul>
218778
219397