in reply to RFC: Class::AutoloadCAN

My first thought is that you're fumbling towards multimethods. Pretty quickly, you're going to be implementing multimethods in PurePerl. Now, I'm not complaining about that idea, seeing as I think multimethods are the best feature of Perl6. But, I think you need to consider it as such when doing design work. If you do that, then you just look at the relevant sections of A12 and implement that. :-)

even though it means using a source filter with the attendant fragility.

No, it doesn't. It requires private 'foo' { ... };, using prototypes. The quotes around the method name is acceptable because base does the same thing.

Update: Actually, you could just say private foo => { ... };. :-)

My wife's blog

Replies are listed 'Best First'.
Re^2: RFC: Class::AutoloadCAN
by tilly (Archbishop) on Apr 11, 2005 at 18:01 UTC
    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.

[reply]
      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