Expressiveness of function types naming

[Kasper Nielsen]

On 20-09-2011 18:04, Paigan Jadoth wrote:
> 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"?
I would prefer the method name accept(). As in "does the predicate 
accept the specified element."

> 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()
>
Yeah I definitely does not like the name Block either. At first I 
thought it had something to do with blocking/non-blocking
IO or functions (as in ForkJoinPool.ManagedBlocker).

Operation is one possibility for a name. I would prefer the name 
Procedure as used in the ParallelArray API.

cheers
   Kasper