The operator usage is so convenient for chaining that we allowed user-defined functions to be used as operators. So, for example, these two usages are equivalent:
my_func(a,b,c)
a.my_func(b,c)
Unfortunately, the converse isn't true. These two usages (of a system-defined operator) are NOT equivalent:
append(a,b) // doesn't work as might be expected
a.append(b)
If system-provided operators could be used as functions, then we could write the flatten operation in a simpler way (as this author expected (see this commit)):
list_of_arrays.reduce(append) // note that this does NOT work now
One could extend this to sets:
list_of_arrays.reduce(union,[]) // note that this does NOT work now, but the next line does work though less simple
list_of_arrays.reduce(function(a,b){a.union(b)},[])
(Note that append works without an initial empty array, but since the first array in list_of_arrays might not be a set (might have duplicates) we need to seed the operation with an empty array.)
The operator usage is so convenient for chaining that we allowed user-defined functions to be used as operators. So, for example, these two usages are equivalent:
Unfortunately, the converse isn't true. These two usages (of a system-defined operator) are NOT equivalent:
If system-provided operators could be used as functions, then we could write the flatten operation in a simpler way (as this author expected (see this commit)):
One could extend this to sets:
(Note that
appendworks without an initial empty array, but since the first array inlist_of_arraysmight not be a set (might have duplicates) we need to seed the operation with an empty array.)