Oof. So you're arguing this as a temporary thing, until our interfaces stabilize? It makes unit testing much harder this way, but I guess I see the rationale.
If we do this, we need to leave a lot out of that base class - there may be some really big differences in implementation of these classes (for example: distributed / hdfs backed matrices vs locally memory-resident ones), so very very little should be assumed in the base impl. I guess more can be done in the vector case, however. -jake On Tue, Nov 24, 2009 at 12:08 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > Yes. Interfaces are the problem that commons math have boxed themselves in > with. The Hadoop crew (especially Doug C) are adamant about using as few > interfaces as possible except as mixin signals and only in cases where the > interface really is going to be very, very stable. > > Our vector interfaces are definitely not going to be that stable for quite > a > while. > > On Tue, Nov 24, 2009 at 12:03 PM, Jake Mannix <jake.man...@gmail.com> > wrote: > > > Well we do use AbstractVector. Are you suggesting that we *not* have a > > Vector interface > > at all, and *only* have an abstract base class? Similarly for Matrix? > > > > -jake > > > > On Tue, Nov 24, 2009 at 11:57 AM, Ted Dunning <ted.dunn...@gmail.com> > > wrote: > > > > > We should use abstract classes almost everywhere instead of interfaces > to > > > ease backward compatibility issues with user written extensions to > > Vectors > > > and Matrices. > > > > > > On Tue, Nov 24, 2009 at 9:38 AM, Grant Ingersoll (JIRA) < > j...@apache.org > > > >wrote: > > > > > > > It seems like there is still some commonality between the two > > > > implementations (size, cardinality, etc.) that I think it would be > > > > worthwhile to keep SparseVector as an abstract class which the other > > two > > > > extend. > > > > > > > > > > > > > > > > -- > > > Ted Dunning, CTO > > > DeepDyve > > > > > > > > > -- > Ted Dunning, CTO > DeepDyve >
