commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [csv] final types
Date Wed, 07 Aug 2013 12:11:46 GMT
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-unsubscribe@commons.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message