in reply to Re: RFC: Class::AutoloadCAN
in thread RFC: Class::AutoloadCAN

My reaction to that thought is that there is no way that I am about to implement multi-methods. First of all doing so introduces complexities that I don't want to figure out. Secondly using multi-methods in a design introduces a level of complexity that I would like to avoid. (Note that I'm likely to be bad at designing something that I personally don't want to use.) Thirdly TheDamian already wrote Class::Multimethods and I've not heard complaints about what he did there.

If there are complaints about Class::Multimethods and people really think that this module should go in the direction of multi-methods, then I'd be glad to give up maintainership to someone who wants to implement that chainsaw.

Replies are listed 'Best First'.
Re^3: RFC: Class::AutoloadCAN
by dragonchild (Archbishop) on Apr 11, 2005 at 18:13 UTC
    Thirdly TheDamian already wrote Class::Multimethods and I've not heard complaints about what he did there.

    I think that's because no-one thinks of multimethods. :-) I seriously doubt that it's been used much, though it should because it solves a lot of problems.

    Now, the reason your module made me think of multimethods is that you're essentially defining multimethods, but from the opposite side. Where Class::MultiMethods allows you to define a series of targets and C::MM goes ahead and figures out what to do based on signatures, Class::AutoloadCAN allows you to specify at the class-level whether or not this class wants to do something about the request. By returning undef, you're indicating to the dispatcher that this is not the correct place for the given signature (which includes the method name).

    Personally, I think that the multimethod route is more maintainable, but that more people will reach for AutoloadCAN because it looks more like something they know. It's a screwdriver and not a tricorder to their hammer. :-)

    My wife's blog

[reply]
[reply]

In Section Meditations