On Sat, May 08, 2010 at 09:36:57PM -0400, Stevan Little wrote:
>
> On May 8, 2010, at 1:27 PM, Eric Veith1 wrote:
>
>> Stevan Little <[email protected]> wrote on 05/08/2010
>> 07:09:47
>> PM:
>>> I have a serious allergy to method attributes, I don't ever use them
>>> so I couldn't comment.
>>
>> Do you mind giving me some bullet points regarding your allergy? I
>> found
>> method attributes rather appealing until now, but if there's some
>> serious
>> trouble ahead, I can still change my design (and would).
>
> Sure, here are my basic bullets:
>
> - The attributes.pm API is horrible and requires all sorts of odd things
> in order to be properly supported inheritance.
And as I understand it, this is why Catalyst requires you to wrap calls
to 'extends' in a BEGIN block (as an example of the 'odd things').
> The MX::MethodAttributes hides much of this, but that's not all ...
>
> - attributes are nothing more then strings, you must parse them
> yourself.
>
> In the simple case this is not that hard, but simple cases have a habit
> of growing into complex cases over time. This kind of thing just adds to
> the fragility of attributes overall.
>
> - attributes must be on a single line
>
> C'mon, really??? This seems simple, but it is a silly restriction that
> can easily trip newcomers up. Again, just added to the fragility in my
> opinion.
>
> - attributes don't actually do *anything*
>
> Well, they do associate string metadata with a function/method, the rest
> you must do yourself.
>
> ---
>
> Personally I lean towards exporting keyword-like functions. I explored
> method attributes for the before/after/around modifiers in the early
> early days of Moose and abandoned them shortly afterwards for all the
> reasons listed above.
A useful idiom is to export a function which applies a trait to the
method metaclass, and then uses that as the method metaclass to install
the given function. You can then do any manipulation you want through
the MOP using actual meta-objects, rather than dealing with string
parsing. This also has the benefit of mistyping "command foo => sub {
... }" as "comand foo => sub { ... }" being a compile error, while "sub
foo : Command { ... }" -> "sub foo : Comand { ... }" is just silently
ignored.
http://github.com/doy/im-engine-plugin-commands/blob/master/lib/IM/Engine/Plugin/Commands/OO.pm
has a (admittedly more complex) example of this, but I'm working on
factoring the important bits out into a separate MooseX module... just
haven't gotten enough tuits yet.
> Honestly, the way it sounds like you are using them (to "mark" methods)
> is likely fine, just keep in mind that it might not scale if your needs
> grow too complex.
>
> - Stevan
-doy
