I'm still not convinced this is warranted, but I voted -0 On Wednesday, August 7, 2013, sebb wrote:
> On 7 August 2013 13:11, James Carman > <ja...@carmanconsulting.com<javascript:;>> > 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:;><javascript:;> > >> For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > <javascript:;> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > >
