commons-dev mailing list archives

luc.maisonobe@free.fr wrote:
> ----- "Jake Mannix" <jake.mannix@gmail.com> a écrit :
>
>> Adding methods to implementations is fine, but not to interfaces - how
>> would
>>
>> that work for client implementations? And everywhere in sight inside
>> of the
>>
>> linear package you have handles on RealVector and RealMatrix, so
>> you'd
>> have to cast to concrete implementation to get access to these new
>> methods...
>
> You are both right.
> I was mainly refering to removing methods as this affects not only implementations but
mainly user code.
> Adding new methods to interfaces is an incompatible change in the sens that existing
implementations need to add this. However, I would be pragmatic here. The odds are very low
that someone dared to add his own implementation of such huge interfaces, they are mainly
for our own use and they are really new as they were created for 2.0. In addition, we would
provide a default implementation for these new methods, so if someone did really create a
class that implements RealVector, he would simply have to say it extends AbstractRealVector
instead. So there is a clear gain to accept this kind of incompatible change as soon as 2.1.
>
> What do other people think about this ?
>
> Perhaps we should also deprecate the gazillion maptXxx and ebeXxx methods, I'm not sure.
+1 for adding AbstractRealVector
+1 to adding map(UnivariateRealFunction) (note
UnivariateRealFunction already exists in the analysis package, so we
should use it) and similar for ebe to AbstractRealVector
+1 to adding iterators to OpenMapRealVector
+1 for all above also applied to FieldVector
-0 for deprecating mapXxx, ebeXxx methods
-1 for removing the mapXXX, ebeXxx methods from the interfaces
-1 for adding methods to the interfaces
+0 for deprecating the "marker" sparse vector and matrix interfaces
so they can be replaced in 3.0, adding what we have settled on as
the right methods such as the iterators above that we will in 2.x
add to the implementation classes.
The -1's stands until at least 3.0, but I need to get to at least +0
on the deprecations so we can do that in preparation.
Like Ted, I am sort of on the fence on the functor-ish approach, but
understand the value and flexibility it provides. At the same time,
we want to maximize ease of use and providing direct methods that do
common things does that. This is especially true for the norms and
other basic operations. Adding abstract classes providing default
implementations for all of the little map*, ebe* methods is a
reasonable compromise that preserves backward compatability.
<bikeshed-warning> There is also a philosophical point that what
you can do to a Vector should be somehow limited to operations that
make sense on a Vector </bikeshed warning>.
Phil
>
> Luc
>
>> On Wed, Oct 14, 2009 at 11:22 PM, Ted Dunning <ted.dunning@gmail.com>
>> wrote:
>>
>>> I think that Luc was referring to non-backwards compatible changes.
>> Adding
>>> methods should not be in this category, but removing them would be.
>>>
>>> On Wed, Oct 14, 2009 at 4:49 PM, Jake Mannix
>> <jake.mannix@gmail.com>
>>> wrote:
>>>
>>>> Question about this: if RealVector is locked as an interface - no
>> changes
>>>> until
>>>> 3.0 - and the Matrix and Vector interfaces have method signatures
>> which
>>>> take
>>>> RealVector as an argument, how is adding new methods to an
>> implementation
>>>> of RealVector (say AbstractRealVector) going to help anyone?
>>>>
>>>
>>>
>>> --
>>> Ted Dunning, CTO
>>> DeepDyve
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org