Since nobody gave their advice, I'll give my own one :-)
The particular case of the Existential Operator (conditional property access
and conditional method call) is probably the more usual one.
The case that I 've come across, which is maybe the more common one not covered
by the Existential
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);
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
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
What/where would be the best place to define such a system,
Github.
and how would
we hook all the specs together to use it?
Define a System object for ES6 that implements the ES6 Loader API and
extends it to dynamically
On Tue, May 27, 2014 at 8:09 AM, John Barton johnjbar...@google.com wrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
What/where would be the best place to define such a system,
Github.
and how would
we hook all the specs together to use it?
Define a System
Le 27 mai 2014 à 17:04, Jasper St. Pierre jstpie...@mecheye.net a écrit :
(...) Namely, the whole ('elements') looks like a method call containing one
argument, rather than having a secret hidden argument as its first.
Yes, it was exactly intended to appear as such, making
The most important problem to iron out with HTML Import + ES6 Loader is the
timing confusion. Both systems use a combination of asynchronous and
blocking-for-dependents loading. The issues could be explored with any of
the existing ES6 pre-standard Loader implementations. (If the developer
uses
This is a great observation, often shared. I recall a related conversation
about a year ago, that echoed a proposal from Yehuda a year prior yet (to
which I hope Yeuhuda can exhume a link).
https://twitter.com/kriskowal/status/400703578605486080
And James Burke brought up some ideas on the
I like the idea, but I agree that the .{ } syntax isn't quite right. For
one thing, on my screen the () are visually very similar to {}, while []
are easily distinguished. The leading dot is also a bit odd. I'd be
interested in seeing some more alternative syntaxes for this idea.
--scott
On
( already covered to receive stones )
```javascript
Object.defineProperty(
Object.prototype,
'through',
{
enumerable: false,
configurable: true,
writable: true,
value: function through(callback) {
for (var a = [this], i = 1; i arguments.length; a[i] =
The HTML version is now posted at:
http://people.mozilla.org/~jorendorff/es6-draft.html
As always, your bug reports not only welcome, they are the main way
things get fixed. File yours:
https://github.com/jorendorff/es-spec-html/issues
-j
On Thu, May 22, 2014 at 7:58 PM, Allen Wirfs-Brock
I like the basic idea. I think the problem is that this is too original
for a language like ECMAScript. There isn't any prior body of experience
of what the use cases and consequences would be.
I'd suggest submitting the proposal to the Traceur people:
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
(Sorry about the formatting in the last one. Trying again.)
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
I'm not sure I like it. Given how other languages use the :: operator,
I'd expect Foo::bar to do some sort of static property lookup for a name
called bar on Foo, not bind the local variable Foo to the local
variable bar. I think bar.bind(Foo) is more than enough. I am OK with
your curryThis
Sorry Nathan but how is this different from extending Object prototype? you
are basically polluting everywhere `::` operator, can't see any less
conflictual scenario than just polluting the `.` one in terms of prototype
On Tue, May 27, 2014 at 11:17 AM, Nathan Wall nathan.w...@live.com wrote:
Jasper St. Pierre wrote:
I'm not sure I like it. Given how other languages use the ::
operator, I'd expect Foo::bar to do some sort of static property
lookup for a name called bar on Foo, not bind the local variable
Foo to the local variable bar.
That's not what the proposed bind operator
From my reading of the email and strawman page, let f = obj::foo; is
exactly equivalent to let f = foo.bind(obj);
Am I wrong? How is the result subtly different?
Really, with obj::foo, I would expect obj::foo to be the same as
obj.foo.bind(obj);, not foo.bind(obj); And even then, I don't think
On Tue, May 27, 2014 at 12:40 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
From my reading of the email and strawman page, let f = obj::foo; is exactly
equivalent to let f = foo.bind(obj);
Am I wrong? How is the result subtly different?
Brendan's saying that the return value of
At the last meeting, I expressed some concern I had about Object.observe
based on feedback I got from Kris Selden of the Ember Core team (the
primary maintainer of our binding system and all-around performance guru).
At the meeting, I was under the wrong impression that Kris had attempted to
On Fri, 23 May 2014, Garrett Smith wrote:
And can we change needs= back to depends=?
I haven't gotten as far as figuring out what the API should look like, so
it's probably too early to bikeshed specific attribute names. :-)
The basic theme of script needs= is making it possible for
@Ian, It seems like the first real question is, based on what will
eventually be in the ES6 Spec for the Loader API, what is the System Loader
as it pertains to the web/browser environment and is there potentially a
need for a specification of it here (or at least outside of tc39).
- Matthew
This sounds good to me. Just a nit, you should define:
Function.curryThis = function(f, base = undefined) {
return function(...args) {
return f.call(base, this, ...args);
};
};
so that you can do, e.g.,
class ImprovedArray extends Array { /* _not_
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, Kris Kowal wrote:
It would be lovely if HTML could be trained to resolve URL's through the
module system.
By HTML here I presume you mean the underlying Fetch mechanism. Could
you elaborate on exactly how
I don't think a URL is the right way to identify everything. Many things
in the Web platform that you could legitimately want to depend on don't
have a URL. For example, a promise, or an inline script block, or an
HTML video element (the latter in particular would have several URLs,
the
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
...
and how would we hook all the specs together to use it?
Define a System object for ES6 that implements the
Le 27 mai 2014 à 20:59, Andrea Giammarchi andrea.giammar...@gmail.com a écrit
:
Sorry Nathan but how is this different from extending Object prototype? you
are basically polluting everywhere `::` operator, can't see any less
conflictual scenario than just polluting the `.` one in terms of
I did indeed !!! Interesting, thanks for the clarification.
On Tue, May 27, 2014 at 3:44 PM, Claude Pache claude.pa...@gmail.comwrote:
Le 27 mai 2014 à 20:59, Andrea Giammarchi andrea.giammar...@gmail.com a
écrit :
Sorry Nathan but how is this different from extending Object prototype?
On Tue, 27 May 2014, Matthew Robb wrote:
@Ian, It seems like the first real question is, based on what will
eventually be in the ES6 Spec for the Loader API, what is the System
Loader as it pertains to the web/browser environment and is there
potentially a need for a specification of it
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
I think the Loader nicely isolates these particular functions: I don't
see any urgency in standardizing them. However the delegation of the
specification of System leaves us in the
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
Is System something that we are expecting some non-ES spec, e.g. Fetch
or HTML, to define?
TC39 members have more than once explained that they expect some non-ES
spec to
On 5/25/14, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote:
On May 19, 2014, at 11:34 , Garrett Smith dhtmlkitc...@gmail.com wrote:
On 1/19/14, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote:
On Jan 19, 2014, at 10:01 , Jasper St. Pierre jstpie...@mecheye.net
wrote:
On 5/27/14, Garrett Smith dhtmlkitc...@gmail.com wrote:
Question: If the even starts at 2am and ends immediately
after 3 am, on May 9, how long is it?
Correction: Mar 9, not May 9.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
___
es-discuss
33 matches
Mail list logo
