Expressiveness of function types naming

[Paigan Jadoth]

Hi list,


May I suggest to refactor the namings in function types like Predicate#eval,
Block, etc. to improve expressiveness?
For example:


Predicate#eval(T)

"eval" sounds very quick&dirty-ly decided like in good old C hacking.
If at all, it should be named "evaluate". But on a closer look: Does a
predicate really evaluate an argument? Not really. A predicate as a whole is
evaluated. The predicate can apply to an argument.
When thinking/talking about a predicate do we say "if predicate isAdult
applies to person p" or do we really say "if evaluating person p with
predicate isAdult yields true"?
Wether to choose "apply(T)" or "applies(T)" or "appliesTo(T)" may be subject
to further discussion (although I'd suggest that if methods in general
represent actions, not states, then "apply" would be the best - and also
shortest - choice.)



Block:

Is "Block" really the best name for a piece of code that is effectively an
operation which you can execute on an argument?
The general conception of a "Block" is this:
{ ... }
Where's the input object in this? Nowhere.
Does anyone really talk about an operation like "... and then the printing
block is applied to the argument"?
Or isn't it more like "... and then the printing operation is executed on
the argument"?

Hence, I'd suggest renaming "Block" to "Operation" and Block#apply() to
Operation#execute()

So it would be for example:
Person joe = ... ;
Operation<Person> printPerson = (Person p) -> { ... };
printPerson.execute(joe);

A "Block" would be an Operation that takes no parameter at all (may be
usefull as well).
Like:

Block printCurrentTime = () -> { ... };
printCurrentTime.execute();



At least that is the terminology for function types that I use in my
work-in-progress next generation collections framework (O.T., but anyway:
sadly no real website atm, only a blog [1] and some first simple documents
[2]).
I planned to replace / merge my local function types with standardized types
from JDK once released, of course. But I can hardly in good conscience
replace an expressive type "Operation" by a confusing one-argument-"Block"
:-(.
Of course my personal stuff doesn't matter for Java as a whole, still I
think many of people will have an unnecessary hard time internalizing /
using / reading the new function types as they are currently named in JDK.


Thank you for reading


[1] http://jadoth.blogspot.com/
[2] http://www.jadoth.net/files/CollectionContentBehaviourConstraints.pdf