Re: [csv] final types

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 > > > 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 some

Re: [csv] final types

On 7 August 2013 13:11, James Carman 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

Re: [csv] final types

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

Re: [csv] final types

>> 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-f

Re: [csv] final types

On 6 August 2013 15:42, Gary Gregory wrote: > On Tue, Aug 6, 2013 at 10:38 AM, sebb wrote: > >> On 6 August 2013 15:32, Benedikt Ritter wrote: >> > 2013/8/6 Gary Gregory >> > >> >> On Tue, Aug 6, 2013 at 10:19 AM, James Carman < >> ja...@carmanconsulting.com >> >> >wrote: >> >> >> >> > I was tr

Re: [csv] final types

On Tue, Aug 6, 2013 at 10:38 AM, sebb wrote: > On 6 August 2013 15:32, Benedikt Ritter wrote: > > 2013/8/6 Gary Gregory > > > >> On Tue, Aug 6, 2013 at 10:19 AM, James Carman < > ja...@carmanconsulting.com > >> >wrote: > >> > >> > I was trying to emphasize "all". > >> > > >> > >> Then, yes, exc

Re: [csv] final types

On 6 August 2013 15:32, Benedikt Ritter wrote: > 2013/8/6 Gary Gregory > >> On Tue, Aug 6, 2013 at 10:19 AM, James Carman > >wrote: >> >> > I was trying to emphasize "all". >> > >> >> Then, yes, except Lexer which is currently subclassed by alternate test >> implementations. >> >> Do we still nee

Re: [csv] final types

2013/8/6 Gary Gregory > On Tue, Aug 6, 2013 at 10:19 AM, James Carman >wrote: > > > I was trying to emphasize "all". > > > > Then, yes, except Lexer which is currently subclassed by alternate test > implementations. > > Do we still need those subclasses? > IMHO they don't make much sense, since

Re: [csv] final types

On Tue, Aug 6, 2013 at 10:19 AM, James Carman wrote: > I was trying to emphasize "all". > Then, yes, except Lexer which is currently subclassed by alternate test implementations. Do we still need those subclasses? Gary > > On Tuesday, August 6, 2013, Gary Gregory wrote: > > > On Tue, Aug 6, 2

Re: [csv] final types

I was trying to emphasize "all". On Tuesday, August 6, 2013, Gary Gregory wrote: > On Tue, Aug 6, 2013 at 8:43 AM, James Carman > > >wrote: > > > I am also -0 to this idea in general. Are we talking about literally > > making all classes final? > > > > What is the difference between a class th

Re: [csv] final types

On Tue, Aug 6, 2013 at 8:43 AM, James Carman wrote: > I am also -0 to this idea in general. Are we talking about literally > making all classes final? > I think there are two points in the "+0" camp, if I can call this camp such that I'd like to outline. 1) Promote composition over subclasssing

Re: [csv] final types

On Tue, Aug 6, 2013 at 8:43 AM, James Carman wrote: > I am also -0 to this idea in general. Are we talking about literally > making all classes final? > What is the difference between a class that is literally final and figuratively final? ;) Gary > > On Tuesday, August 6, 2013, Gary Gregory

Re: [csv] final types

I am also -0 to this idea in general. Are we talking about literally making all classes final? On Tuesday, August 6, 2013, Gary Gregory wrote: > I think the idea is that it promotes composition instead of > subclassing as the extension pattern. > > If I wanted the parser to produce a different k

Re: [csv] final types

I think the idea is that it promotes composition instead of subclassing as the extension pattern. If I wanted the parser to produce a different kind of record, Gary On Aug 6, 2013, at 4:44, Emmanuel Bourg wrote: > Le 05/08/2013 19:34, Gary Gregory a écrit : > >> Thoughts? > > -0, that's not ve

Re: [csv] final types

Le 05/08/2013 19:34, Gary Gregory a écrit : > Thoughts? -0, that's not very friendly to people willing to extend [csv]. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mai

Re: [csv] final types

On 5 August 2013 18:46, Benedikt Ritter wrote: > 2013/8/5 Gary Gregory > >> In https://issues.apache.org/jira/browse/CSV-42 >> >> One of the comments is to make all classes final. >> >> Right now, only our package private types are final. >> >> Thoughts? >> > > Sounds reasonable (to make all clas

Re: [csv] final types

2013/8/5 Gary Gregory > In https://issues.apache.org/jira/browse/CSV-42 > > One of the comments is to make all classes final. > > Right now, only our package private types are final. > > Thoughts? > Sounds reasonable (to make all classes final). Benedikt > > Gary > > -- > E-Mail: garydgreg...

[csv] final types

In https://issues.apache.org/jira/browse/CSV-42 One of the comments is to make all classes final. Right now, only our package private types are final. Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition