Here is the obvious solution. Create a subclass. Use that in code you control. In code you don't control, you won't be calling those methods anyways...
On Tue, Sep 20, 2011 at 8:24 PM, Bill Moseley <[email protected]> wrote: > Thanks for the feedback everyone. > > On Wed, Sep 21, 2011 at 12:20 AM, Zefram <[email protected]> wrote: > >> Bill Moseley wrote: >> >The other approach is a utility module using Exporter[*] -- then do >> > is_in_future( $dt ), but I'm not thrilled by that. >> >> This is the most sensible approach. It won't step on anyone else's toes. >> > > Yes, and it's a time-honored usage and probably the way to go. > > What doesn't "thrill" me by that approach is our old code has a collection > of modules like this in various "Util" namespaces, and looking at them it's > clear to see that it's often really code that the programmer didn't know > where else to put. Perhaps that's a separate issue, though, but often > it's indicative of a design problem. Hard to articulate, but sets off > waring bells in the back of my head. ;) Kind of like seeing C for loops in > Perl. > > > Plus, if is_in_future() is something that only can be passed a DateTime then > it kind of feels like it's a method. > > Don't worry too much about which syntax you're using. >> > > Are you saying don't worry that a Moose Role is being used an an Exporter > replacement? > > Here's my original post of the code that is doing that: > > http://www.nntp.perl.org/group/perl.moose/2011/09/msg2236.html > > > Thanks again, > > -- > Bill Moseley > [email protected] >
