On 7 August 2013 13:11, James Carman <ja...@carmanconsulting.com> wrote: > What exactly does it hurt by leaving them non-final? It's not like we have > to support folks doing stupid things. One user doing something > silly doesn't impact other users either. I guess I don't understand the > paranoia here.
It's not paranoia, it's reserving flexibility. If classes are final, we know that they cannot be extended by 3rd parties, so we can change them in ways that would break sub-classes. > On Tuesday, August 6, 2013, Torsten Curdt wrote: > >> >> 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 <javascript:;> >> For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
