Earlier I noted that __DATA sections are not polymorphic. The source code of Class::DBI::DATA::Schema shows a potential means to workaround this: 
{
    my %cache;

    my $statements = sub {
        my $h = shift;
        local $/ = ";";
        chomp(my @sql = <$h>);
        return grep /\S/, @sql;
    };

    sub run_data_sql {
        my $class = shift;
        no strict 'refs';
        $cache{$class} ||= [ $statements->(*{"$class\::DATA"}{IO}) ];
        $class->db_Main->do($_) foreach @{$cache{$class}};
        return 1;
    }

}

[download]
The code above was designed to be called as a class method, meaning: 
My::Class->run_data_sql

[download]
The key would be to replace: 
my $class = shift;

[download]
with 
my $class = ref shift();

[download]
so that the sub could be called as an object method: 
$object->run_data_sql

[download]
and not a class method and then work out its original class via ref

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality.

Replies are listed 'Best First'.
Re: Working around non-polymorphic __DATA__ sections
by hardburn (Abbot) on Oct 20, 2003 at 13:38 UTC
    my $class = ref shift();

    Umm, why? If it's called as an object method, you should probably be handling everything internally as an object, not a class. If, by chance, you really do need to handle things as a class method for a particular section of code, then you can always call ref when you need to, but you should always keep the orginal object around if that's what you were passed.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    :(){ :|:&};:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]
      If it's called as an object method, you should probably be handling everything internally as an object, not a class.
      This is a tried-and-true stmt which ha nothing to do with the topic at hand :)

      The idea is to get at the __DATA__ of the invocant even in the subroutine resolves to a parent as I discussed in the earlier node.

      Polymorphism supports subroutines but not __DATA__ sections

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality.

[reply]
[d/l]
[select]
Re: Working around non-polymorphic __DATA__ sections
by simonm (Vicar) on Oct 20, 2003 at 18:46 UTC
    For what it's worth, this looks like a good case for the common idiom for object-or-class methods: 
      my $self = shift;
  my $class = ref($self) || $self;

    [download]
[reply]
[d/l]
Re: Working around non-polymorphic __DATA__ sections
by Anonymous Monk on Oct 21, 2003 at 09:32 UTC
    Yes, filehandles, variables ... are not polymorphic (data rarely is)
[reply]

Back to Meditations