commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Math] Fluent API or not? (Was: [math] suggestion: [...] on descriptive statistics)
Date Mon, 19 Jan 2015 11:35:28 GMT
Hello.

Some time ago, we had a discussion about the "fluent API"
paradigm:
   http://markmail.org/message/3fjvucyz7rax4cyi

The excerpt of the conversation below is typical of the antagonism
between proponents of the evolution of the library and proponents
of stability.

In particular, when most people agreed on an API change (based on
identified problems and "by-design" improvements, a.o. increased
robustness, easier maintenance), it is unexpected to encounter
opposition later on, and have to justify from scratch the value of
a similar proposal, for every part of the library.

It is a loss of time for everybody.

A project must have a clear direction, to avoid discussing matters
at lower levels when the high level policy has been defined.

A divisive stand is prone to scare would-be contributors: Not knowing
where CM is heading to does not encourage people to spend time looking
at ways to improve the codebase.


Regards,
Gilles



>>>>>> [...]
>>>>>>
>>>>>> As I said above, what we need is a simple value object.  I am 
>>>>>> fine
>>>>>> with dispensing with the interface though.  What is useful is 
>>>>>> the
>>>>>> value object.
>>>>>
>>>>> If so, I'd insist that each class provides its _own_ "Values" 
>>>>> type,
>>>>> as an inner class (to be as close as possible to the producer),
>>>>> thus:
>>>>>
>>>>>   StatisticalSummary.Values (instead of 
>>>>> "StatisticalSummaryValues")
>>>>>   DescriptiveStatistics.Values
>>>>
>>>> The synchronized versions also produce these.  Why insist on the
>>>> two-level names?
>>>
>>> 1. Sync vs non-sync:
>>>    They produce the (final) "values" of the _same_ type, so the 
>>> base
>>>    class's "Values" can (and should) be used.
>>>
>>> 2. StatisticalSummary and DescriptiveStatistics
>>>    Two different classes: thus a priori, one should not be forced 
>>> to
>>>    produce the same set of values.
>>
>> That is not what I am proposing.  DescriptiveStatistics would get
>> its own value object.
>>
>> I am -1 on eliminating the existing, already used StatisticalSummary
>> VO.  I would like to add DescriptiveStaticsValues that works
>> similarly, but includes more statistics.
>>
>>>    If the classes are meant to always evolve in parallel, I feel 
>>> that
>>>    it could (and, if so, should) be enforced by the design.
>>>
>>> 3. [After you draw my attention to the "Synchronized..." classes.]
>>>    (a)  It is dangerous to have the synchronized version inherit
>>>    from the non-sync one: forgetting to update the subclass (as a
>>>    new method is added to the parent) will make it thread-unsafe.
>>>    Composition is necessary (and, in this case, not more work since
>>>    all methods must be overridden either way) to detect this kind 
>>> of
>>>    bug as early as possible.
>>>    This is surely a change to be implemented in 4.0 in order to
>>>    increase robustness.
>>>    [Sorry to touch a venerable class (@since 1.2)!]
>>
>> -1 on this.  These classes and APIs have been stable for a very long
>> time.  As new methods are added, it is simple and easy to make the
>> required updates.
>
> It's also simple and easy to miss the updates.
>
>>>    (b)  Again, if the sync and non-sync versions are meant to 
>>> evolve
>>>    together (as they obviously are), there shouldn't be two
>>>    distinct classes, but the synchronized version should probably
>>>    be created by a factory method (à la 
>>> "Collection.synchronized..."
>>>    methods).
>>
>> -1 to gratuitous API change giving no benefit to users.
>
> It's no more "gratuitous" than what we have done along the
> years in other packages; it's a real improvement.
> But if you want to oppose modifying old code on the basis that it
> is old, there is no room for discussion.
>
> Synchronization is an implementation choice and does not warrant
> an independent type. The factory method would return an anonymous
> sub-type of "DescriptiveStatistics".
>
>
> Gilles
>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message