On 30 January 2011 16:45, Stephen Colebourne wrote:
> On 30 January 2011 15:11, sebb wrote:
>> On 30 January 2011 09:09, Stephen Colebourne wrote:
>>> The modern standard for altering immutable classes was laid down by
>>> Joda-Time
>>>
>>> strategy = strategy.withCommentStart("#");
>>
>> Not s
On 30 January 2011 15:11, sebb wrote:
> On 30 January 2011 09:09, Stephen Colebourne wrote:
>> The modern standard for altering immutable classes was laid down by Joda-Time
>>
>> strategy = strategy.withCommentStart("#");
>
> Not sure I undestand that.
An immutable setter, as in
http://joda-time
On 30 January 2011 09:09, Stephen Colebourne wrote:
> The modern standard for altering immutable classes was laid down by Joda-Time
>
> strategy = strategy.withCommentStart("#");
Not sure I undestand that.
> Really, though the question is whether it shoudl be immutable or not.
+1
Whatever deci
The modern standard for altering immutable classes was laid down by Joda-Time
strategy = strategy.withCommentStart("#");
Really, though the question is whether it shoudl be immutable or not.
Stephen
On 30 January 2011 04:51, Jacopo Cappellato wrote:
> Hi Gary,
>
> I initially proposed the cha
Hi Adrian,
yes this is what I was thinking when I mentioned the factory method.
Jacopo
On Jan 30, 2011, at 8:06 AM, Adrian Crum wrote:
> From my perspective, if DEFAULT_STRATEGY, EXCEL_STRATEGY, or TDF_STRATEGY are
> mutable, then copies of them should be returned in a factory method. Ideally,
From my perspective, if DEFAULT_STRATEGY, EXCEL_STRATEGY, or TDF_STRATEGY are
mutable, then copies of them should be returned in a factory method. Ideally, a
selector would be passed to a factory method:
CSVStrategy strategy = CSVStrategy.getInstance(CSVStrategy.DEFAULT_STRATEGY);
-Adrian
O
Hi Gary,
I initially proposed the change when I noticed the following code in one of the
automated tests of common-csv:
CSVStrategy strategy = (CSVStrategy)CSVStrategy.DEFAULT_STRATEGY.clone();
strategy.setCommentStart('#');
TestCSVParser parser = new TestCSVParser(new StringReader(c
indeed, if not, it doesn't worth the value changing the actual design :P
Have a nice WE!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Jan 29, 2011 at 9:49 PM, Gary Gregory
wrote:
> Are people really using these classes in an MT way? These seem like the kind
>
Are people really using these classes in an MT way? These seem like the kind
of classes you do not share between threads. My op only though.
Gary
On Jan 29, 2011, at 12:27, "Simone Tripodi" wrote:
> Hi all guys!!! :)
> I'd suggest to apply Jacopo's suggestion, making strategies' fields as
>
Hi all guys!!! :)
I'd suggest to apply Jacopo's suggestion, making strategies' fields as
final would help classes becoming thread-safe; to fix the issue of
construction described by Stephen, it would be useful adding builder
classes (optionally implemented as static inner classes).
WDYT? HTH, that'
Thank you Stephen,
I understand this; alternatively we could implement a factory method that
clones DEFAULT_STRATEGY, EXCEL_STRATEGY, TDF_STRATEGY; but I will definitely
postpone any decision, it is not a big deal for me and we can wait for
additional feedback.
Jacopo
On Jan 29, 2011, at 1:1
Traditionally, many commons projects has taken no position on the
correct way to instantiate objects, whether via constructor or bean
methods. This was to allow construction from tools such as Velocity.
It is also still easier to construct using Spring via bean methods
rather than the constructor.
Hi all,
in my opinion all the setter methods should be removed from the CSVStrategy
class: in this way the fields will only be set using the constructors and they
will become readonly.
The main issue I see with the current implementation is that a calling method
can modify the values of the fie
13 matches
Mail list logo
