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.
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:;> > >
