On Wednesday 28 Apr 2010 08:04:31 Daniel Pittman wrote:
Shlomi Fish shlo...@iglu.org.il writes:
On Tuesday 27 Apr 2010 15:51:07 Stevan Little wrote:
On Apr 27, 2010, at 3:36 AM, Shlomi Fish wrote:
After merging XML-Grammar-Fiction and XML-Grammar-Screenplay, I have
accumulated several questions about Moose, so I'd post each one in a
separate post to keep each thread single-topic. (I hope it's OK.)
The first one is how to implement a Class::Std/Perl 6-like walkmeth:
*
http://blog.gmane.org/gmane.comp.lang.perl.qotw.discuss/month=2007070
1
* http://search.cpan.org/perldoc?Class::Std (search for CUMULATIVE).
[SNIP]
My question is: is there a better way to do it using Moose? (Or one of
the MooseX modules?) Instead, should I implement my own private logic
or create a new MooseX module?
No, that is pretty much how you would do it. Take a look at
Moose::Object::BUILDALL, it does the same thing.
OK, thanks. I might create a small MooseX::AccumArray distro out of it.
If you do get around to looking at this, I have a couple of times played
with the idea of either hacking on Class::MOP[1], or writing an extension,
to do some more of the method combination bits that CLOS used to do.
Specifically, I have run across the need for:
'and' and 'or' method combination[2], both with most-specific-first and
least-specific-first ordering — various validations like ACL-style
authorisation, and data validation, benefit from those.
The accumulate to array method combination you mention is also quite
useful, but a bit obvious right now.
CLOS also had min, max, and plus method combinations, for which I can see
some logic exposing in Moose also — and probably some of the ...write
your own too.
OK, now we're talking about generalising the walkmeth functionality of what I
need. I didn't get so far into studying CLOS (I studied CL mostly from the
book Practical Common Lisp), or forgot it, but I think I know what you mean.
Everything you describe is a sub-case of reduce like the one in List::Util,
although the concept predates List::Util and Perl itself by a long time:
http://search.cpan.org/perldoc?List::Util
Now, the problem with such a reduce is that it has to know to short-circuit in
case it's a cumulative (and...) or (or...) operation. And then we need to
decide whether we code one distinct accumulating meta-method for every such
operation (as accum_array, accum_and, accum_or, accum_min, accum_max,
accum_sum, etc.) or that we implement a generic reduce and then implement each
specific accumulator based on it (which may result in slower code.).
And naturally I now remember that perfect is the enemy of good, and that
there's a saying in Hebrew that caught a lot - did not catch anything.. Oh!
Decisions, decisions.
Regards,
Shlomi Fish
Daniel
Footnotes:
[1] This embeds the standard method combination inside
Class::MOP::Method::Wrapped as a private method internally; it doesn't
look terribly hard to extend to either use external method combination
classes, or to support non-standard (eg: not before, after, around)
decorators ... which makes me think I have missed something in my
look-but-not-touch investigation so far.
[2] I suspect that Perl users would like a and-true and and-defined
variant of both of these, that short-circuit when the value is false
and undefined respectively, where CLOS users didn't.
--
-
Shlomi Fish http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html
God considered inflicting XSLT as the tenth plague of Egypt, but then
decided against it because he thought it would be too evil.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
