As an update on this thought, I began exploring exactly what the API impact would be. I think there is a big impact for those that subclassed or implemented components, but probably little for clients of the standard implementations.
I found one ugly snag when replacing Users and Items with IDs (Objects). These entities need an ordering; Users and Items implement Comparable. When dealing with IDs it is not sufficient to use Object; we must declare IDs as - get this - Comparable<Comparable<?>>. This turns into a mess. One alternative is to assume all IDs are Strings, since some components like FileDataModel already necessarily assume this. But I don't like it. I am inclined to defer this big change for now since the code is getting new attention as part of Mahout and it is not a good time for a big change. I imagine it will happen sooner or later for performance reasons; the framework is eternally short on performance rather than felxibility so the tradeoffs have to start happening. More thoughts are welcome. Sean On Apr 22, 2009 1:16 PM, "Sean Owen" <[email protected]> wrote: Agree about Preference -- there will have to be some kind of object that represents an item-value pair. While the interface probably goes away, the "GenericPreference" class probably stays. Anyone who customized a component probably has to make some non-trivial changes. People that just use standard components actually may have little or no changes. Thanks for the input, I will await more comments. I should also add that performance has become my top priority, as it always seems that the code consumes too much time and memory. So this is a large reason why I favor a change that could simplify and speed up the code and data structures, even if it means reducing flexibility slightly. Sean On Wed, Apr 22, 2009 at 1:05 PM, Andre Panisson <[email protected]> wrote: > I think removing t...
