Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

All I am saying is that the proof is in the pudding. This is a tiny bit of code. If you like decorators, just write it and we can discuss it. Aside from that, I don't want to talk and talk and talk... Gary On Wed, Oct 29, 2014 at 1:24 PM, Adrian Crum < adrian.c...@sandglass-software.com> wrote:

Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

Writing code before agreeing on a design is putting the cart before the horse. If there is immediate push-back on a design, then why would anyone want to write the code for it? I don't see how HttpComponents is relevant. So what if they deprecated their decorators? Oracle continues marching

Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

This should be something simple to use, it's just a parser for a 'simple' file format. I get a format, a parser and my data. If each new feature is a decorator I'm going to end up creating 5 classes to use 5 features, no thanks. Like you said, it could be a matter of personal taste. Over at HttpCom

Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

Generally speaking, good designs are not based on class count. If we simply add methods to the parser every time a user comes up with a new use case, then eventually we will end up with a single class that tries to be all things to all people. The decorator pattern is ideally suited for situa

Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

On Wed, Oct 29, 2014 at 4:13 AM, Benedikt Ritter wrote: > Hi Gary, > > what do you think about the Decorator approach, suggested by Adrian Crum in > JIRA? > In theory, it's OK, but in this specific case, it does not seem to me worth the cost (an extra class) and complexity (it makes the client c

[exec] Release 1.3

I see some changes (see changes.xml) that ready to go for a 1.3. Does any one have more to do for 1.3? Any one feels like an RM? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second E

Re: svn commit: r1635052 - in /commons/proper/csv/trunk/src: changes/ main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/

Hi Gary, what do you think about the Decorator approach, suggested by Adrian Crum in JIRA? Benedikt 2014-10-29 6:44 GMT+01:00 : > Author: ggregory > Date: Wed Oct 29 05:44:40 2014 > New Revision: 1635052 > > URL: http://svn.apache.org/r1635052 > Log: > [CSV-131] Save positions of records to ena