is this technique I describe actually superclass acessing subclass data

No.

Superclass objects cannot get to the constant - only objects in the sub-class in question.

What you are defining is an abstract interface - every Question class should have a get_table_name method (or whatever your constant is called).

Each sub-class is then giving its own concrete implementation to get_table_name (or whatever).

It's a commonly accepted technique.

Take a look at Refactoring: Soft-code class name in factory method and Re: Re: Extending object you don't create which do similar things with class names rather than table names.

No, adrianh is absolutely correct. In fact, this is very good style because it allows inheritance of behavior while allowing alterations to that behavior transparently based upon the concrete subclass you are actually instantiating.

Here's an example of bad, inflexible, child-snooping that you want to be concerned about:

package FamilyMember; # the parent class of Son, Daughter
sub new {
    my ($class, $args) = @_;
    my $self = bless({}, $class);
    if ($class eq 'Son') {
        $self->askSantaFor('A Truck!');
    } elsif ($class eq Daughter') {
        $self->askSantaFor("Subscription to Martha Stewart's 'Living'"
+);
    }
return $self;
}

sub askSantaFor {
    my ($self, $wish);
    push @{$self->{things_to_ask_for}}, $wish;
}
[download]

What happens if you need to add a new subclass called StepDaughter? You have to go to the superclass and modify the constructor. The better way is just what you've done, and in this silly example the solution would be either to override askSantaFor in each subclass, or (even better) provide a class specific method, perhaps called wishList, that provides the appropriate parameters to the method called from the superclass constructor. Thus the above example code could be changed to:

sub new {
    my ($class, $args) = @_;
    my $self = bless({}, $class);
    $self->askSantaFor($class->wishList());
    return $self;
}
[download]

Hope that helps, DJ