David Green wrote: > Jon Lang wrote: >> In "Aiasing methods in CPAN roles", David Green wrote: >>> >>> I don't want my special log() method to work only for other types that >>> explicitly do NumLog; I want it to work for any type that directly "does >>> Numeric does Logging". >> >> But if Logging doesn't do Numeric, why should it be expected to >> provide a method that assumes that it does? > > Well, I don't want all objects that do Logging to do Numeric; I just want to > have custom methods for those that do happen to do both.
...which strikes me as a perfect argument for putting those methods in a role that does both. > If I can put ad hoc compound types into a signature, e.g. foo(Numeric > Logging) instead of foo(NumLog), then why shouldn't it be possible to define > a method that way? Or conversely, should compound types in signatures be > disallowed, and forced to use "NumLog"/whatever also? Because a method is part of a role, and ought to abide by the same terms by which the role abides. If Logging doesn't do Numeric, it shouldn't have any methods in it that won't work unless it does. -- Jonathan "Dataweaver" Lang
