Comment 5 for bug 337494

I don't understand the comment about clashing with .values either.
I explicitly implemented the API to be conceptually similar to
ResultSet.values. For example:

result = store.find(...).values(MyClass.foo)
subselect = store.find(...).select(MyClass.foo)

In both cases you're "specializing" the result set to give you
MyClass.foo values. The difference is that in the first case you're
mutating the ResultSet and in the second case you're getting a
Select expression. Both the mutated ResultSet and the Select
expression will yield the same values, they just operate
differently.

Anyway, that said, I'd be happy to change the name to something
else. But, since there seems to be resistance to the changes here
I'm wondering about creating a Subselect expression that works
something like this:

result = store.find(MyClass)
subselect = Subselect(result, MyClass.foo)

That would keep the ResultSet API the way it is, but still provide a
fairly straight-forward way to create a Subselect from a ResultSet.
We could implement Subselect to work for the simple cases we have
now, and in time extend it to deal with the hairier cases. When we
determine that Subselect does all the things we want it to, we can
revisit the ResultSet API to make the feature more friendly to use.

How does that sound as a way to move forward?