But yes, with chromatic's suggestion, I can keep the tie and lose the "incestuous relationship", as you've humorously phrased it, so it's all good :)

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};
[download]

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.

I guess I didn't make myself very clear in my last response -- when I say I'm writing a class generator, I mean that I'm designing a module with functionality similar to Class::MethodMaker. It is not a base class that I'm writing, but a module that generates class methods from "boilerplate" at run-time, thereby simplifying recurring issues that come up when writing OO Perl, like class-level and base-class-level data, attribute defaults, attribute accessors/mutators, etc. In practice, there will be no speed hit if the option to tie the class is not used, since no "tieing code" will be generated. I do want to leave the programmer the option to create such code; however, so I can simplify the process of writing such code as well.

Although you've now got me questioning whether there is any point in writing code to generate from "boilerplate" TIEHASH/FETCH/STORE routines when they will in probably just get overridden anyway. I definitely have to think in greater depth about what sort of generated code could even be useful in regards to the tie feature. Thanks for the insight.