Sugar for *.prototype and for calling methods as functions
This request is the very definition of little things that go a long way. I
write a hell of a lot of code that boils down
to Function.prototype.bind(Function.prototype.call/apply,
Somebuiltin.prototype.method). The fact that there's builtin way to
accomplish string.split("\n").map(String.split) (split just as an
example) is annoying in how obvious it is that it should work, and how
often I need them. In fact I think there's some modification to
Spidermonkey that has this? Array.* and String.* being functional versions
of the prototype methods.
error in the example should be:string.split("\n").map(String.trim)
The established way of doing this is [].forEach, "".trim, {}.valueOf. I imagine that by now, there would be no performance penalty, any more, because most engines are aware of this (ab)use. But it is indeed not very intention-revealing. It might make sense to wait with this proposal until classes are finished, but they probably won’t introduce any changes at this level.
I would ask as an exploratory idea: is there any interest in, and what problems exist with exposing most {Builtin}.prototype.* methods as unbound functional {Builtin}.* functions. Or failing that, a more succint expression for the following:
Function.prototype.[call/apply].bind({function}). Array.prototype.[map/reduce/forEach].call(arraylike, callback) Object.set('key', va)
Basically, JavaScript has incredible usage potential as a functional language but has almost not built in support in terms of applyable functions. It teases you with its charms and then gives no direct payout, instead asking you to put just one more dollar in for the good stuff.
On 21 February 2012 13:59, Brandon Benvie <brandon at brandonbenvie.com> wrote:
I would ask as an exploratory idea: is there any interest in, and what problems exist with exposing most {Builtin}.prototype.* methods as unbound functional {Builtin}.* functions. Or failing that, a more succint expression for the following:
Function.prototype.[call/apply].bind({function}). Array.prototype.[map/reduce/forEach].call(arraylike, callback) Object.set('key', va)
There is a proposal for making available existing functions via modules in ES6:
If there are methods missing from this list that can reasonably be used as stand-alone functions, then I'm sure nobody will object to adding them.
There is a proposal for making available existing functions via modules in ES6:
If there are methods missing from this list that can reasonably be used as stand-alone functions, then I'm sure nobody will object to adding them.
Beautiful, no more constructors-as-poor-man’s-namespaces.
All generic methods could be in such modules, with uncurried this. But, with generic methods I’m undecided, they also make sense as “static” methods:
strawman:array_statics
Sorry if it already has been picked up (I searched and didn't found anything close that).
In my last months of work with JavaScript what that I miss a lot in ES5 syntax is:
Array#foEach.call(listThatsNotArray, fn);
Array#forEach@(listThatsNotArray, fn));
or
trimmedListOfStrings = listOfStrings.map(String#trim@);
Last example is same as following in ES5:
trimmedListOfStrings = listOfStrings.map(Function.prototype.call.bind(String.prototype.trim));
This two proposals will make methods easily accessible for some functional constructs, and I think might be revolutionary for those who favor such functional way of programming.
Let me know what do you think about that.