Grails Service

layoutService.groovy

 public list(){
        Layout.executeQuery('from Layout where user is null')
    }

    public list( User user ){
        Layout.executeQuery('from Layout where user = :user or user is null', [ user: user ])
    }

And fwiw, I'm not totally against adding overloaded methods to CF.

It is like the ORM argument all over again. Those who don't like (or fully understand) ORM were against it. Not saying people have to use it, but would love it if we had the option

As for having to overload more if need be, I think for an API (what I am working on right now), it works better as it 'self documents' a little better than the CF way with a ton of optional arguments.

I'm not sure that I'm against it at all - options are great. Just that for my own use of CF, I find that the dynamic argument style is more elegant and uses less and more readable code - in general. The difference with this and ORM though is that it changes the core nature of the language (ORM does not). There are plenty of good statically typed languages, after all.

Not sure I agree that overloading methods would 'change the core nature of the language'. Make it possible to do so, but not mandatory. Problem solved.

I disagree that dynamic argument styles are more elegant and is more elegant. Method overloading may result in more methods (more lines of code), but each method would, in my opinion, more elegant that the uber-method you would need to handle this with dynamic/optional arguments.