Inline
On Jul 22, 2009, at 10:07 AM, Sean Owen wrote:
I wanted to announce a change that could break some people who extend
the recommender engine library. Actually, I am threatening to make one
small change now, in anticipation of a couple larger changes.
The change is:
1. "ID" values become Comparable<?> instead of just Object. Example:
User.getID() return value.
This just makes sense, I hope. The only real requirement I have for
keys is that they have an ordering, preferably a natural one. So this
expresses it. Better than the way it is currently expressed:
+1
2. Remove the generic type from classes like GenericUser, GenericItem.
This type was bound as "<K extends Comparable<K>>" so you could only
use a comparable key with these classes anyway. But the associated
interfaces, User and Item, did not carry this generic type since the
type then spread virally throughout the code until it was a mess. Any
component that touched a User or Item had to also express their
generic type. Pretty soon you have DataModel<(user key type), (item
key type)> and more, which doesn't make sense
But it really didn't make sense to have this generic type and not put
it in the interface declaration.
Sounds right.
This was causing messes in cloning User or Item objects meaningfully:
something(Object itemID) {
if (itemID instanceof Long) {
return new GenericItem<Long>((Long) itemID), ...);
} else if (itemID instanceof Integer) {
...
} ...
}
I think this only affects people that have extended the components or
integrated more deeply than just calling the components as-is. That
is, if you're already making calls like recommend("3595", 20) then
nothing changes.
The deeper change I've been threatening for a while is to remove the
User and Item abstractions entirely. It's a big change, but removing
these objects and dealing only in IDs simplifies things, and improves
memory and speed notably. Forcing instantiation of these objects is a
problem in several places. That change I'm still contemplating since
it's big... but, this change will actually make it somewhat easier.
I've often found the User/Item thing confusing in Taste. Sometimes
you use Ids, sometimes Strings, sometimes the objects. I think
dealing with Ids is a lot simpler, but you might consider some utility
tools that make it easy for users to lookup the real things.
Soliciting thoughts before I pull the trigger.
These all sound reasonable, but rather big, so I assume you will be
adding patches and doing the work in JIRA so that others can try out
before committing. Sounds like a perfect fit for a lazy consensus
model of: "Here's a patch that addresses this issue. I plan on
committing in X days" (for X > 2 or 3, usually)
-Grant
