A MooTools Code Riddle For You
IMing w/ Valerio today and he shares this method with me, and I swear it’s a damned riddle. If I were in a maze with a minotaur and had to tell you what this code does or die, I might very well die. I did manage to figure it out, but it took me a few moments during which I think I might have had a dumb look on my face and even possibly might have drooled. There’s a reason why Valerio designs frameworks and I do not.
A gold star to the first person who can guess what this function is designed for (note, it’s using some new methods coming in MooTools 1.3, so you’ll have to guess what those do by their names):
Object.duck = function(object){
return extend(Object.map(Object, function(value, key){
return function(){
var o = value.apply(Object, [object].concat(Array.from(arguments)));
return (typeOf(o) == 'object') ? Object.duck(o) : o;
};
}), {unduck: Function.from(object)});
};
Follow @clientcide on twitter to get notified of new posts.
To follow me personally on twitter, follow @anutron.
January 29th, 2009 at 4:32 pm
Do I see some Pyton concepts in here? Looks to me as if it returns an instance of Object where the first parameter to each method is the object passed to duck. But hey, I could be miles away. It’s a tough one, certainly a brain teaser.
January 29th, 2009 at 4:36 pm
From the looks of it, you might be assigning an object to be the instance that
thiswill refer to inside any of Object’s functions, as well as an unduck function which will remove the binding back out.Definitely obscure, though.
January 29th, 2009 at 4:40 pm
You’re warm, but not quite on it. Stan is really, really close (so close that I won’t say he’s wrong, technically). I’ll wait till tomorrow and post back here with the answer if no one nails it.
January 29th, 2009 at 5:01 pm
Extending stans explanation. The function will either return the result of the apply or the duck’ed version if the return value is an .
but the use of it escapes me.
January 29th, 2009 at 5:15 pm
*cheating and reading commits*
.from will return a function returning the value if value is not a function.
January 29th, 2009 at 5:16 pm
Maybe it’s use is to take generic functions and make them specific to a certain object… Reverse genericing? Kind of bindy too. Is the point of this that the mootools methods on elements and things will be automatically bound, so that you need not do so to use those methods as event handlers and stuff like that?
January 29th, 2009 at 5:21 pm
ding ding ding ding ding
I’m gonna say that Jenna is close enough to be a winner – You get a gold star!
It takes an object (any javascript object) and takes all the generic methods on Object and applies them to that object. So for instance:
//we have a generic iterator for objectsObject.each = function(object, fn){...};
//usage: Object.each(myObj, fn);
duckieObj = Object.duck(myObj);
//duckieObj now has .each method:
duckieObj.each(fn);
//duckieObj.unduck(); >> returns myObj again
It basically extends an object (returning a new one) where the one that was passed in is a private variable protected by an enclosure.
January 29th, 2009 at 7:01 pm
I’d rather a carrot than a gold star, but, whatever. :)
January 29th, 2009 at 9:16 pm
I think we’re going to have to implement a MooTools quiz, that all devs need to score at least an A on. Jan and I compiled some JavaScript gotchas a while back. Let’s see who the real ninjas really are… ;)
January 29th, 2009 at 10:50 pm
That was awesome! Another!
January 30th, 2009 at 12:45 am
This would only work with generics functions that take as the first param an object that we want to “duck”
January 30th, 2009 at 9:19 am
Ionel, that’s how generics work in MooTools.
@Garrick, I’ll try and come up with another one. Feel free to send me your own if you have something really abstract and creative.
January 30th, 2009 at 11:05 am
@Aaron: I want to disagree. I don’t think we should have more of these. One of the coolest things about Mootools is the code: it is simply child’s play to navigate around… or should I say was. I don’t think it is right to encourage developers to come up with riddles like the one above. As I did find out myself, it takes quite a bit of time to ‘run’ the code in your head. Mootools has a lot of great features and if we are to come up with a quiz, let’s focus on those rather than bang our heads with riddles as such?
January 30th, 2009 at 11:21 am
Stan, there’s nothing wrong with a bit of fun every now and then. Valerio sent this to me because he thought it was interesting. He wanted to see if he could solve a problem but this was just an exercise. When working on the MooTools core we often come up with very abstract things that are kind of beautiful to look at but ultimately may or may not make it in the release. Putting this code in front of everyone here makes them look at it and parse it and consider it. That’s a good exercise if you ask me, and a fun one, too.
January 30th, 2009 at 11:25 am
@Aaron: you are right in everything you said. I love creative ‘code’. I think my key point here is – let’s do it in moderation; let’s not overdo it. Yes, it certainly was fun especially at 3am.
January 31st, 2009 at 2:24 am
@Stan: Sure, clean easy to read code may be easy to read, might help you get the job done quick. We have a lot of clean code around. I don’t think I’ve ever learnt anything of value from reading clean code. Just gotten the job done. It’s the crazy code, the inventive endlessly recursive mega-chained gibberish that teaches and empowers me and many others. :)
Lets not overdo clean code. Mootools is after all an open source project. What drives Mootools, the very core of it’s existence, like most open source, is to have fun and learn, as well as getting things done. The more fun you take out of the equation, the less people will want to work on the framework, and that has a very direct relationship with the quality and dependability of the framework.
So in summary, fun is good. That is all.
January 31st, 2009 at 10:44 am
I would express it in a slightly different way than @Jenna. I would say that the code we’re used to looking at is often very legible because it is very explicit in nature. I.e. what the code is doing is very apparent. But at the heart of the framework lives some exceptionally abstract code that is difficult to understand. Methods that allow you to build much more complex things on top of them are often gibberish. Look at Fx.js – a lot of it looks totally unusable, but it’s the abstract quality of the code that allows you to build Fx.Morph, Fx.Tween, Fx.Elements and others on top of it. Figuring out code like that presented here helps you both learn how to understand the meaning and usefulness of the heart of MooTools (and JavaScript), but it will also show you the virtue of designing your own code that way.