in reply to Working around non-polymorphic __DATA__ sections

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

Replies are listed 'Best First'.
Re: Re: Working around non-polymorphic __DATA__ sections
by princepawn (Parson) on Oct 20, 2003 at 15:52 UTC
    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]

In Section Meditations