make a combinator from a MOP

Where would I be without RSS? In Firefox, you can make a Live Bookmark folder from a feed, then put that folder into the bookmarks toolbar folder. Turn on the bookmarks toolbar from the view menu, and then you have one-click access to checking up on your feeds.

This technique is most handy for sites that aggregate or host many blogs but offer one, combined feed. It was through the use.perl.org Most Recent Journals feed that I found the provocatively titled post Moose::AutoBox - Ruby ain't got nothin on us . The more that I investigated what Stevan wrote about, the more impressed I was by what he's working on. Moose::AutoBox, strangely enough, uses an autobox module and Stevan's Moose module to enable runtime modification of methods to call on Perl's builtin types. The runtime object modification happens through the Moose module, which as I understand it is for providing a nicer interface to the Class::MOP module. And the Class::MOP module is an implementation of a Meta Object Protocol for Perl 5 objects. It came about because he wanted to use some Perl 6 object features in Perl 5 (he's not alone; there are other modules out there for doing Perl 6-ish stuff in Perl 5).

I'm skeptical about the usefulness of a class morphing at runtime, but once again I admit to not ever doing it. I simply haven't found a need for it in the software I write. Actually, I don't use plain old reflection or introspection much either. It seems to me that a combination of interfaces and runtime composition of objects can accomplish the effect of changing a class's behavior at runtime, but in a cleaner and type-safe way (see strategy or command or dependency injection design patterns). In fact, reading Stevan's post reminded me of a different post I read a while back on Oreilly, Is a Java macro language enough? . It's good reading, and it discusses both a MOP and Lisp-style macros for Java. I think he concludes that bolting on such sophisticated features at this stage in the game would result in a more complicated language, when what we want is to make Java easier not harder to work with.

Back to Stevan's post. He shows an example of using the Code part of Moose::Autobox to apply the Y combinator, which is part of the module, to an anonymous code block to make it recursive. What's the point of this in a language that supports recursion in the usual fashion: by using the function name inside its definition? There is none, unless you really, really don't want to name your recursive function for some reason...like if you're defining it on the spot so you can pass it to a higher-order function. Anyway, if you're curious about the Y combinator like I was, be prepared to read many parentheses in links like this ruby example, or this Scheme example . The Scheme link is about several abstract topics, but the Y combinator is at the bottom. They don't teach this stuff in Java class, people. They just don't.