>> I am also -0 to this idea in general. Are we talking about literally >> making all classes final?
In general I am a big fan of starting out with everything as much final as possible and control where subclassing is explicitly intended. Also helps with the API design. Only later make them non-final if requested. When you release early and often it's a non-issue and it's easier to control your cross version compatibility issues > 1) Promote composition over subclasssing as a customization pattern. This > is a design point that is philosophical for some. Really depends on the code. In general I am leaning towards that camp. > 2) We can make final classes extensible after 1.0, but we cannot make > non-final classes final in 1.x without breaking compatibility. Yup! > The current code, IMO, is not really designed for customization by > extensibility, otherwise, for example, I'd expect CSVParser to have a > method called newRecord(), in addition to nextRecord(). No clue about the CSV code base myself - but I think there you have your answer then. My 2 cents cheers, Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
