Comments on: Feature or Bug, You Decide: Argument Reordering in Groovy http://enfranchisedmind.com/blog/posts/groovy-argument-reordering/ programming, politics, & other religious issues Tue, 09 Mar 2010 23:06:00 +0000 hourly 1 By: Robert Fischer http://enfranchisedmind.com/blog/posts/groovy-argument-reordering/#comment-33692 Robert Fischer Wed, 20 Aug 2008 03:19:34 +0000 http://enfranchisedmind.com/blog/?p=758#comment-33692 By rearranging the arguments, you can play fast-and-loose with your API. For instance, I could call custom(class, prop1:"val1", prop2:"val2"), or I could call custom(prop1:"val1", prop2:"val2", class). This actually makes life easier for people constructing builders, because you can specify "required" values, allow the user to put the map where they like, and collect everything that's left as varargs. To allow that kind of flexibility through the traditional Java API would require a plethora of carefully-wired methods. Given defaulted parameters, it's actually clearer to the developer and easier on the user to allow the flexibility. And, of course, if you're the user and you want to be anal about it, you can always use explicit maps to force the argument order. Once you get used to the idea, it's actually pretty nice. Reminds me a bit of Perl's pseudohashes, but cooler. The only thing is that I wish they would enforce the closure constraint if I'm expecting to be passed a block. It seems like an odd decision to force that into userspace while everything else is taken out up front. By rearranging the arguments, you can play fast-and-loose with your API. For instance, I could call custom(class, prop1:”val1″, prop2:”val2″), or I could call custom(prop1:”val1″, prop2:”val2″, class).

This actually makes life easier for people constructing builders, because you can specify “required” values, allow the user to put the map where they like, and collect everything that’s left as varargs.

To allow that kind of flexibility through the traditional Java API would require a plethora of carefully-wired methods. Given defaulted parameters, it’s actually clearer to the developer and easier on the user to allow the flexibility. And, of course, if you’re the user and you want to be anal about it, you can always use explicit maps to force the argument order.

Once you get used to the idea, it’s actually pretty nice. Reminds me a bit of Perl’s pseudohashes, but cooler.

The only thing is that I wish they would enforce the closure constraint if I’m expecting to be passed a block. It seems like an odd decision to force that into userspace while everything else is taken out up front.

]]> By: Josh http://enfranchisedmind.com/blog/posts/groovy-argument-reordering/#comment-33691 Josh Tue, 19 Aug 2008 20:05:59 +0000 http://enfranchisedmind.com/blog/?p=758#comment-33691 I read the JIRA tickets and the documentation, but I'm failing to see why this reordering is a good thing. What am I missing? Why do you like it? I read the JIRA tickets and the documentation, but I’m failing to see why this reordering is a good thing. What am I missing? Why do you like it?

]]>