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:
orno warnings 'redefine'; package Time::Piece; sub _mktime { ... }
sub Time::Piece::_mktime { ... }
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?
In reply to Re: Re: Re: Tracking Inheritance Directly due to Hybrid Methods
by djantzen
in thread Tracking Inheritance Directly due to Hybrid Methods
by mojotoad
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |