I have a syntax proposal, but it goes along with a slightly different way of
thinking of this.
The proposed bind operator[1] can take a function which acts as a method and
make a call to it with a specific receiver without the receiver needing to have
the method defined as a property (basically a nicer syntax for `call` and
`apply`). Given a bind operator, this problem reduces to just having a way to
take a function and turn its first argument into its `this`. So good syntax
can be achieved in two steps.
Steps:1. Turn the function into a method.2. Invoke with bind operator.
To solve step 1, we could have something like `Function.curryThis` which does
the opposite of "uncurryThis":
Function.curryThis = function(f) { return function(...args) {
return f(this, ...args); }; };
Example use:
// ES5 Array.from(obj);
// Proposal var toArray = Function.curryThis(Array.from);
obj::toArray();
Another example:
// ES5 Object.getOwnPropertyDescriptor(window.HTMLFormElement.prototype,
'elements').get;
// Proposal var getOwnPropertyDescriptor =
Function.curryThis(Object.getOwnPropertyDescriptor);
window.HTMLFormElement.prototype::getOwnPropertyDescriptor('elements');
Perhaps sugar could be added to do both steps in one with another operator (say
`:::`).
// ES5 Object.getOwnPropertyDescriptor(window.HTMLFormElement.prototype,
'elements').get;
// Proposal
window.HTMLFormElement.prototype:::Object.getOwnPropertyDescriptor('elements');
It's the same proposal as yours with slightly different syntax. And I think
the syntax makes some sense given a bind operator `::`.
[1] http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
Date: Tue, 27 May 2014 11:04:52 -0400
Subject: Re: Syntactic sugar for using a function as if it were a method of
its first argument
From: jstpie...@mecheye.net
To: claude.pa...@gmail.com
CC: es-discuss@mozilla.org
It's fairly incomprehensible to me, and doesn't really have any advantages over
writing it out the long way:
Object.getOwnPropertyDescriptor(window.HTMLFormElement.prototype,
'elements').get
window.HTMLFormElement.prototype{Object.getOwnPropertyDescriptor}('elements').get
They're both the same line length. I find the former more direct and the latter
more confusing. Namely, the whole ('elements') looks like a method call
containing one argument, rather than having a secret hidden argument as its
first.
On Tue, May 27, 2014 at 4:17 AM, Claude Pache <claude.pa...@gmail.com> wrote:
Often a function can be thought as if it were a method of its first argument.
Compare:
Array.from(obj); /* vs */ obj.toString()
Object.getPrototypeOf(obj); /* vs */ obj.__proto__
Array.forEach(obj, func); /* vs */ obj.forEach(func)
Math.clz32(num); /* vs */ num.toFixed(2)
and note the inversion of the order of the terms.
So, I propose to introduce syntactic sugar to replace the terms in correct
order, e.g.,
foo{Bar.baz}(...args)
// or (to be bikeshed)
foo.{Bar.baz}(...args)
as a synonym of:
Bar.baz(foo, ...args)
Here are two examples of use:
window.HTMLFormElement.prototype{Object.getOwnPropertyDescriptor}('elements').get
document.querySelectorAll('input[type=checkbox][name=Select_ID]:checked').{Array.from}().map(e
=> e.value).join(',')
The wins are:
* a strict left-to-right order, instead of having methods appearing
alternatively at the right and at the left of its main operand, thus improving
readability;
* enabling the use of the Existential Operator for the new form, e.g.:
window.HTMLFormElement?.prototype?{Object.getOwnPropertyDescriptor}('elements')?.get
(Note that `?{` suffers from the same grammar problem as `?[` and `?(`, and the
due fix for the two latter would also fix the former.)
—Claude
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jasper
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
