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 ggreg...@apache.org:
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
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
http://www.manning.com/bauer3/
JUnit in Action, Second
On Wed, Oct 29, 2014 at 4:13 AM, Benedikt Ritter brit...@apache.org 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
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
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
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
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:
