Sugar for *.prototype and for calling methods as functions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Sugar for *.prototype and for calling methods as functions

medikoo
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:

1. Syntax shortcut for '.prototype'. Instead of writing String.prototype.trim I'd love to be able to write for example String#trim  (it's not proposal, just example how it may look).
As most native ES methods are generic there are a lot of valid use cases for that e.g.:

Array#foEach.call(listThatsNotArray, fn);

2. Syntax sugar for calling method as a function. In following examples I just place '@' at end of method that I'd like to be run as function.

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.

--
Mariusz Nowak
https://github.com/medikoo
http://twitter.com/medikoo
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Brandon Benvie
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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Brandon Benvie
error in the example should be:`string.split("\n").map(String.trim)`
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Axel Rauschmayer
In reply to this post by medikoo
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.

On Feb 21, 2012, at 12:16 , Mariusz Nowak wrote:


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:

1. Syntax shortcut for '.prototype'. Instead of writing
String.prototype.trim I'd love to be able to write for example String#trim
(it's not proposal, just example how it may look).
As most native ES methods are generic there are a lot of valid use cases for
that e.g.:

Array#foEach.call(listThatsNotArray, fn);

2. Syntax sugar for calling method as a function. In following examples I
just place '@' at end of method that I'd like to be run as function.

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.

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Brandon Benvie
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.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Andreas Rossberg-4
On 21 February 2012 13:59, Brandon Benvie <[hidden email]> 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:

http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard

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.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar for *.prototype and for calling methods as functions

Axel Rauschmayer
There is a proposal for making available existing functions via modules in ES6:

http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard

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:

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss