Review Request: CR#8001634 : Initial set of lambda functional interfaces (original) (raw)
Remi Forax forax at univ-mlv.fr
Thu Nov 1 12:23:16 PDT 2012
- Previous message: Review Request: CR#8001634 : Initial set of lambda functional interfaces
- Next message: Review Request: CR#8001634 : Initial set of lambda functional interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/01/2012 04:40 PM, Brian Goetz wrote:
I also think that UnaryOperator and BinaryOperator are name that are too long, I think that Op and BinOp are better. The names UnaryOperator and BinaryOperator are a bit inconsistent with the rest of the names. The naming model we have (which may well be inadequate) implies a "natural" arity for a base name (arity(Predicate) = 1, arity(Factory) = 0). We then use prefixes like Bi to suggest a different arity, such as in BiMapper or BiBlock. So it would be more consistent to choose an arity for Operator (2?) and have Operator and UnaryOperator / UniOperator. Do we like that better?
What trouble me is that most of the SAMs are one word, or two with primitive specialization, but UnaryOperator/BinaryOperator or UniOperator are already composite names, so it make them look as inconsistent with the rest of the SAMs.
Or, is the "natural arity" scheme naive and we should have arity prefixes on all SAMs? (I hope not.)
I hope not too :) I perfer no arity prefix for all SAMs.
Rémi
- Previous message: Review Request: CR#8001634 : Initial set of lambda functional interfaces
- Next message: Review Request: CR#8001634 : Initial set of lambda functional interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list