I'm willing to be convinced but what is the theoretical argument for this? I am all for interfaces *and* abstract classes. You write the API in terms of interfaces for maximum flexibility. You provide abstract partial implementations for convenience. Everyone is happy.
The best argument I've seen against it is that it can be overkill. In super-performance-critical situations the dynamic dispatch overhead is perhaps worth thinking about, but that's rare. What else? I take the point about interfaces changing, but this is significant when you expect a lot of third-party implementers of your interfaces. I don't think that is true here. On Tue, Nov 24, 2009 at 8: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 >
