I would suggest still losing it. If you later decide you
want the tie in certain submodules, consider the following
trick:
package A;
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $obj;
%$obj = @_;
return bless ($obj, $class);
}
sub TrialMethod {
print "The method was called\n";
}
package A::SubClass;
@ISA = A;
sub new {
my $proto = shift;
my $obj = $proto->SUPER::new(@_);
tie (%$obj, 'Some::Tie::Class', $obj);
return $obj;
}
package Some::Tie::Class;
sub FETCH {
print "A fetch happened\n";
}
sub TIEHASH {
my $class = shift;
my %hash = %{ shift() };
return bless \%hash, $class;
}
package main;
my $thing = new A::SubClass(qw(hello world));
$thing->TrialMethod();
$thing->{foo};
See? The example is useless, but it shows that without
taking the hit of assuming a tie implementation in your
base class you have in no way affected your ability to
create subclasses that can take advantage of a tie. You
are already this polymorphic. Why force the speed hit?
In fact the generic approach is more polymorphic
than the tie implementation you are doing. Why? Because
you moved key initializations into TIEHASH, so anyone who
wants to override your tie with an interesting
implementation needs to couple their TIEHASH more tightly
with yours than they should need to.
In fact this is a basic principle of OO design which is
good to know. The point of OO is to provide encapsulated
behaviour, aspects of which are easy to override.
Therefore in your design do as little as you need to with
as clean an interface as you can come up with, and plan on
using the ease of overriding to later add on any features
that could come in handy. Then anyone who doesn't use the
flexibility, doesn't pay. But the potential is still
intact. |