On 5/27/14, Garrett Smith 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 mailing list
es-discu
On 5/25/14, Norbert Lindenberg wrote:
> On May 19, 2014, at 11:34 , Garrett Smith wrote:
>
>> On 1/19/14, Norbert Lindenberg wrote:
>>>
>>> On Jan 19, 2014, at 10:01 , Jasper St. Pierre
>>> wrote:
>>>
On Sunday, January 19, 2014, Garrett Smith
wrote:
>>>
[...]
> I should have
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson 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 de
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 define System.
Ah, great. (Sorry if I sound dumb here, I'm very ne
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson 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 weir
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 i
I did indeed !!! Interesting, thanks for the clarification.
On Tue, May 27, 2014 at 3:44 PM, Claude Pache wrote:
>
> Le 27 mai 2014 à 20:59, Andrea Giammarchi a
> écrit :
>
> > Sorry Nathan but how is this different from extending Object prototype?
> you are basically polluting everywhere `::`
Le 27 mai 2014 à 20:59, Andrea Giammarchi 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 prototype
There is no
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson wrote:
>
>
> On Tue, 27 May 2014, John Barton wrote:
> > On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
...
>
> > > and how would we hook all the specs together to use it?
> >
> > Define a "System" object for ES6 that implements the ES6 Loader A
>
>
> 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
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson 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 this
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_ overloa
@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 Robb
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
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
imple
On Tue, May 27, 2014 at 12:40 PM, Jasper St. Pierre
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 foo.bind(obj) is subtly
di
>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
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
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 wrote:
> I have a syntax pr
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 "c
(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 receiver
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
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:
https://code.google.com/p/traceur-compiler
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
w
( 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] =
arguments[i++])
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
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 topic.
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 a
Le 27 mai 2014 à 17:04, Jasper St. Pierre 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
`obj.{Object.getOwnPropertyDesc
On Tue, May 27, 2014 at 8:09 AM, John Barton wrote:
>
>
>
> On Fri, May 23, 2014 at 5:04 PM, Ian Hickson 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 E
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson 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 load CSS
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 s
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); /
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 O
34 matches
Mail list logo
