System.out.println(i18n( FILE_NOT_FOUND, file))

for example. Anyone who reads this knows what the code is doing (I think it cannot be said the same for the $ method).

BTW, good post about fluent interfaces.

I’ve been using the $() shortcut in Reposita Messages, as a lookup for i18n bundles and keys. System.out.println($( FILE_NOT_FOUND, file)) is easier to read than …(bundle.getMessage(…)). I’m not sure if in your case it would be more readable with days(5) and hours(3), the $() seems to me a try to rebuild the Ruby way with 5.times. It’s clean, but times(5) and days(3) is as readable and no need to extend Integer.

Peace
-stephan

I’m not sure what DSL really means, when mixed with a base language. A real DSL would be it’s own language, but then Rails wouldn’t be a DSL also.

I wrote about a fluent interface to Google collections: http://stephan.reposita.org/archives/2007/10/17/creating-a-fluent-interface-for-google-collections/

and how to automatically create fluent interfaces from an Java interface with reflection:

http://stephan.reposita.org/archives/2007/10/10/fluent-interface-and-reflection-for-object-building-in-java/

I also hope that closures in Java 7 will move us in the right direction.

Peace
-stephan

–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.

Good thought proving article.enjoyed reading.

Thanks
Prashant Jalasutram
http://prashantjalasutram.blogspot.com/

Date before = $(2).days().before().now();
Date from = $(5).hours().from(aDate);

Kind Regards

Just as a reference for anyone interested in DSLs, another way of creating DSLs is to
create a grammar using antlr and use that grammar to generate code.
Although I know that is more complicated not to mention that solutions with generated
code can sometimes be very “spooky”
Congratulations for the well written article.
Regards,

Paulo Abrantes

This type of methods are useful for human usage, not for frameworks like Hibernate,JSF, etc. where getters and setters are more suitable. As a summary, I would use fluent interfaces with Builder Pattern for construction and a POJO for the object/entity.

Yes this._name is obviously not needed (I started with a ‘name’ property and I changed after, but I missed removing this :D)

public Person name(String name){
this._name=name;
return this;
}

be compatible with existing accessors in a javabean? Do I need the setter method

public void setName(String name) {
this._name=name;
}

co-existing with the new one above? I wouldn´t like to count on two separate methods to do that. How’d be the getter like?

Btw, if the bean fields start with a leading ‘_’, ain´t using this._field=field kinda superfluous?

Good post.