JDK 8 calendar builder

Re:JDK 8 calendar builder by Someone on Sunday May 26, 2013 @01:47PM (#5771797)

Method cascades do not guarantee that the object gets properly initialized. Let's say you do

    var calendar = new Calendar()
      ..year = 2013
      ..date = 6;

Neither the year setter nor the day setter can throw, as they cannot know that there is no month setter in your code.

So, what month is the date set to after that code? Builder.build(), on the other hand, can throw when called on a partly initialized builder. A builder also can (I don't know whether Java's builder do this) accept variants such as:

   Builder.setYear(2012).setDay(60); // February 29

   Builder.setYear(2000).setDay(MONDAY).setWeek(14);
   // Monday of week 14 of week 2000

So, builders have their advantages.

[ Parent | on HN ]

Re:JDK 8 calendar builder by mythz on Monday May 27, 2013 @12:15PM (#5775150)

In that case, you're just describing about maintaing a fluent API, which is painfully verbose to maintain for every type.

[ Parent | on HN ]

Re:JDK 8 calendar builder by Someone on Monday May 27, 2013 @02:00PM (#5775753)

It also is joyful in the sense that it will throw exceptions at the place where you make errors and not at some later time (for example, you won't get a 'oops, there is no February 29 in 2013' exception when you print a date). I think the designers of Java value that higher than the extra work of language implementers.

[ Parent | on HN ]

Re:JDK 8 calendar builder by mythz on Wednesday May 29, 2013 @06:23PM (#5789608)

Whilst other language implementers prefer to come up with re-usable language features that scales to help everybody keep a clean and concise code-base.

[ Parent | on HN ]