My hovercraft is full of eels

It's really the lack of named parameters that's hurting here, isn't it? Feel free to campaign to get this RFE re-opened: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4124331.

I kind of miss named parameters in Java too. However, here's a way to do something kind of similar in Java:

public static Map toMap(Object ... values) {
Map result = new HashMap();
for (int i = 0; i < values.length; i += 2) {
result.add(values[i], values[i + 1]); // suitable length checking here of course
}
}

This then lets you do, if you want:

destination.transfer(toMap("amount", 20.00, "to", destination));

Hacky, but it kind of works.

You can also use a Command pattern here:

public class Transfer extends Command {
public Transfer to(Account account) { ... ; return this; }
public Transfer from(Account account) { ...; return this; }
public Transfer amount(float amount) { ...; return this; }
public void execute() { from.transfer(amount, to); }
}

Then invoke it like:
new Transfer().amount(20.00).from(firstAccount).to(secondAccount).execute();

With a command pattern, I'd look at generating the commands to avoid writing them. Annotations would be a friend here. Maybe something like this:

public class Account {
...
@command(params = { "amount", "to" })
public void transfer(float amount, Account to) {
...
}
}

Then write something to generate a command called Transfer, that takes an Account in the constructor (to invoke the transfer method on), with a float property called "amount" and an Account property called "to". Saves the scut work, and also helps enforce the "Good Idea(tm)" that Commands should delegate straight down to the domain model.

Yup. Hence my use of the words "at least as complicated..." :-)

Go on, do a groovy example and do us proud Simon !

Wouldn't it be great to see Objective C-on-rails or Smalltalk-on-rails ! Especially with all the nice OSX tools for objective C.

Done ;-)

I'd like to point out that the map based ones are actually very nasty for people not intimately familar with the method being called. Having to know what keys are going to be retrieved is rather icky. Named parameters at least will give you a nice warning: the parameter you tried to assign to does not exist, or something similar.

In any case, complexity is a mixed bag. For example, if you go the generated command route, yes there is complexity setting it up. But that's a one-off cost, and you don't have to worry about it anymore - future effort is on par with the Objective C version. Depends if the cost savings to be made are high enough, really, which in turn is related to how large the project is, and wether you could reuse the generated command infrastructure later.

Personally, I don't find account.transferAmountTo(20.00, destination) to be a big deal. And, unlike ruby, the compiler will tell me if I get the order wrong.

But I still wish Java had named parameters.

The Groovy one looks nice. I like groovy, I like its integration with all the APIs we know and love from java, I like being able to jump into and out of plain old java.

Thanks for wasting an extra 10 mins of your time Simon ! appreciated.

I found it interesting that you didn't cite Rails as an example of a DSL in Ruby. I realise that may well be because you've dodged hype and avoided playing with it, but you've made me think about the relationship between Rails and the DSL concepts.

At the most straightforward level Rails defines a set of different DSLs for various aspects of the problem space. For example, this snip drawn from the Depot application code in the PragProg book shows a DSL for defining relationships between database tables and fields, and another for talking SQL to the database (there are many others):

class Product < ActiveRecord::Base
validates_presence_of :title
validates_presence_of :description
validates_presence_of :image_url
validates_uniqueness_of :title
validates_numericality_of :price
validates_format_of :image_url,
:with => %r{^http:.+\.(gif|jpg|png)$}i,
:message => "must be a URL for a GIF, JPG, or PNG image"

def self.salable_items
find(:all,
:conditions => "date_available <= now()",
:order => "date_available desc")
end

But then there's a whole lot of other less explicitly DSL stuff that to a greater or lesser extent is still domain-specific machinery also implemented within the one Ruby language. You've got some simpler domain-specific but not-so-much-language mark-up in the form of various config and test fixture YAML files; development tools and stubs; code generators; and HTML with embedded code - and with my current lenses in I can see this last one as a DSL with an inverted syntax, where instead of the generic language hosting a DSL, you end up with domain-specific data hosting a generic langauage.

I can argue that Rails takes the "one scripting language to wire them all" flavor of DSLs and reapplies it at the level of a programming framework rather than just that of the programming language.

Hi Anthony,

You're absolutely correct. I hadn't _actully_ thought about Rails, primarily because I haven't played with it...yet. My focus was more on languages that easily support or even encourage the practice; I picked a few examples based on my _actual_ experience. If Ruby had fully-blown named parameters it'd be very close to my language of choice.

I never liked Struts (just ask anyone), gave up on WebWork before I managed to foist it upon an unsuspecting project, haven't used Tapestry, etc. and you can take JSF and, well, you know :)

As for Rails, it looks great, sounds good but ironically, until I hear one of the Rails evangelists write a piece on what they _don't_ like about it and how they got around those difficulties, I'll just take a wait-and-see attitude.

Cheers,

Simon

thanks!