Hi Benedikt,
I accept that, and I respect your decision. I don't want to argue with you on this, I just want to understand your decision. From Effective Java, I learned "if you are facing a constructor with lots of optional arguments, consider using the builder pattern". Can you explain, why you think it is not appropriate in this case? You said it is too verbose, but it's just one additional call, compared with what we have now.
You said it, it's an additional call. For [csv] I'd like to focus on a simple and user friendly API. "Effective Java" is a good reference, but I think we should find a balance between theorical "by the book" perfectness and user friendliness.
The advantage of the builder (sorry now I'm arguing :) is, that nobody has to remember to validate the format. Even if validation is something that is package private, that could lead to the point where someone forgets to add that line. Now you could say we have unit tests for that. But isn't it the responsibility of an object to verify that it is being instantiated into a valid state?
There was no validation before and nobody complained. I think no other CSV API validates its parameters. I thought it was harmless and convenient to add it, but now if it's used as an argument to make the API more verbose I'd rather remove it completely.
Also we don't know yet, if there always will be only one package in the library. What if, we add another package (o.a.c.csv.beanmapping or what ever) and we want to use CSVFormat there. Then we would have to make validate public, exposing it to the outside world.
Well, why not if that's necessary at this time. Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signature
