Function parameter order (original) (raw)
Tim Peierls tim at peierls.net
Tue Nov 13 08:23:48 PST 2012
- Previous message: Function parameter order
- Next message: Function parameter order
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Nov 12, 2012 at 10:34 PM, Sam Pullara <spullara at gmail.com> wrote:
This proposal makes a lot of sense to me. Not sure how nice it will look in the APIs that use them but it will be obvious what is going on and matches my expectations on type ordering.
Mine, too, mostly. It took me a little while to understand that T2 is short for ObjectObject, and that Object marks a slot to be specified via the type parameters, in left-to-right order. I was also a little confused initially by the omission of a ToObject when no primitive types are involved.
What would lower the entry barrier, I think, would be to use a name for slots that isn't already a valid actual type parameter. "Ref" would work nicely; it's short and accurate.
So I'd prefer Function.RefRef.ToRef<String, Pattern, Iterable> rather than the shorter Function.T2<String, Pattern, Iterable>.
For very common cases, you could have Function<F, T> extend Function.Ref.ToRef<F, T> (currently Function.T1<F, T>) and Predicate extend Predicate.T1. (I have to confess that my main reason for wanting this is to avoid having to change my existing code. :-) )
--tim
- Previous message: Function parameter order
- Next message: Function parameter order
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list