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 .
