[vector] Prototype of apply() method on Vector

[Brian Goetz]

> I want put a stake in the ground, moving toward these goals,
> not getting there immediately, but solving an important
> tactical problem.
>
> Right now, the Vector API has too many methods.
> I count 128 methods in FloatVector.  There are 95
> arithmetic methods, and half of those (44) are
> seldom-used (but important) transcendentals.
> There are several versions of even important
> methods such as add, min, abs, etc.
>
> Most of these methods can be folded into a handful
> op-driven method of the form Kishor has prototyped.

Note that this is really a choice between two not-so-great options, 
because they pit the needs of API maintainers against the needs of API 
users.

The lots-of-sharp-methods approach has a large API surface, which means 
more maintenance and duplication, and is more difficult for programmatic 
analysis, but ... yields code that is more readable, because it puts the 
business operations (e.g., "ADD") front and center in the user's face.

The fewer-more-abstract-methods approach is simpler to maintain and 
analyze, easier to abstract over, and has less duplication, but code is 
often less readable, because what's in the user's face is the less 
helpful BINARY_OP, and you have to peek into the parentheses to figure 
out what's going on.  APIs that treat the business logic in this way 
have the characteristic that "all code using API XYZ looks the same", 
because it is dominated by .binaryOp(...) calls, and you have to peek 
into the "data" to find out what is really going on.

The winning move is to align the needs of both parties.  (Gee, thanks, 
Captain Obvious.)  One thing that would look like winning to me is if 
the latter approach lent itself to better composibility; where it was 
possible to derive an operation from others, such as deriving a 
sum-of-squares binary op from add and multiply binary ops, so that one 
can create higher-level operations that make up for the fact that the 
operation is secondary in the code expression.  I think we're a ways 
away from being able to do that right now?

Overall I am still hopeful that John's refactoring will yield a pleasant 
API, I mostly just wish we could push it farther.