in reply to Re: Re: Tracking Inheritance Directly due to Hybrid Methods
in thread Tracking Inheritance Directly due to Hybrid Methods

Okay, I think this is sinking in; gmtime and localtime are exported to your current module in such a manner that they can be called directly, that is, not on any package name or reference. Doesn't this mean then that even if you override _mktime you still have to override the exported functions so that they'll call your version of _mktime rather than the version in the package in which they were originally defined? I think you'd have to actually redefine it rather than override it, as in: 

no warnings 'redefine';
package Time::Piece;
sub _mktime { ... }

[download]
or 
sub Time::Piece::_mktime { ... }

[download]

You know, the more I think about this, the more I think Time::Piece was written this way because it's not supposed to be subclassed ; ) Wouldn't using it as a mix-in for your modules give you all the flexibility you need? For what reason does the functionality you're looking for require an IS-A relationship to Time::Piece?

Replies are listed 'Best First'.
Re(4): Tracking Inheritance Directly due to Hybrid Methods
by mojotoad (Monsignor) on Jul 25, 2002 at 22:04 UTC
    Yes, the redefinition route might be the final result. Plus re-exporting gmtime() and localtime().

    As for the why of my desire for an isa relationship...I was building an "enhanced" timepiece that has some extended functionality...but I still wanted the behavior of Time::Piece, particularly the existing object methods, overloaded math operator functionality, stringification, etc.

    It was beginning to look like I was going to have to override everything in order to do that, which sort of defeats the purpose of subclassing. So I appealed to my fellow Brethren for better ideas.

    I think you have the right idea, though...given isa, I'm probably going to have to kiss all and redefine _mktime()

    Thanks for the sounding board,
    Matt

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom