On Fri 14 Jun 2013 04:24, Luke Hoban writes:
> (I believe this introduces the only place that "var x" is allowed but
> cannot have an initializer?).
FWIW, there are similar situations in the same spot of the grammar: "let
x" can't have an initializer in for-of or for-in, and neither can "var
x"
On Jun 13, 2013, at 7:24 PM, Luke Hoban wrote:
>>> From: Erik Arvidsson [mailto:erik.arvids...@gmail.com]
>>> This was from back in the days when Google code search was still available
>>> and the only hits we found were from test suites.
>
>>> On Jun 13, 2013 8:54 PM, "Brendan Eich" wrote:
>
>> From: Erik Arvidsson [mailto:erik.arvids...@gmail.com]
>> This was from back in the days when Google code search was still available
>> and the only hits we found were from test suites.
>> On Jun 13, 2013 8:54 PM, "Brendan Eich" wrote:
>>We had some web crawling help, IIRC. We also figured w
This was from back in the days when Google code search was still available
and the only hits we found were from test suites.
On Jun 13, 2013 8:54 PM, "Brendan Eich" wrote:
> Luke Hoban wrote:
>
>> The ES6 draft grammar no longer allows the following, which was legal ES5:
>>
>> for(var i = 1
Luke Hoban wrote:
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why?
Yes, to simplify and tighten up grammar (and engines). We reckoned that
only testsuites counted on this. This was re
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why? (Of course, there are
exceedingly limited practical uses of this, but that alone doesn't seem to
justify a breaking change).
Luke
_
Looking at the discussion on
https://code.google.com/p/v8/issues/detail?id=90
it seems the V8 team is waiting for TC39 to tell them that they have to switch
to a stable algorithm.
An agenda item for the next meeting?
Norbert
On Jun 13, 2013, at 14:40 , Brendan Eich wrote:
> Just confirming: I
On Thu, Jun 13, 2013 at 4:42 PM, Kevin Gadd wrote:
> I'll state it again since I guess maybe the third time is the charm:
>
> When I said 'always stable' or 'always unstable' i was referring to which
> implementation the browser uses, not what the sort actually does. There's
> nothing beneficial
I'll state it again since I guess maybe the third time is the charm:
When I said 'always stable' or 'always unstable' i was referring to which
implementation the browser uses, not what the sort actually does. There's
nothing beneficial about the fact that an unstable sort happens to
rearrange elem
On 6/13/13 at 3:53 PM, feli...@gmail.com (felix) wrote:
Always-unstable is trivial...
Not really. Doing it with a test case that has only one record
is hard. It is also hard if the test case has all different
records (according to the sort field(s).
BTW _ I think having only one sort which
oh dear ... I forgot I wrote that Trait proof already ... well ... I am
willing to change/improve/modify that script if necessary, just let me know
what's the final decision (yep, that was an early shim out of emtpy specs
:D)
thanks for pointing that out
On Thu, Jun 13, 2013 at 4:18 PM, Peter Se
If one thinks about how Andrea Giammarchi might have come up
with his already reliable implementation of [Object.mixin] ...
[https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js]
... the need for changing the order of arguments most probably
will become less desirable.
I
Rick talked about a third argument but if that won't exist I like multiple
sources too.
It's also more suitable as Object.mixin(target, ...[source1, source2,
source3]) for predefined collections of mixins to reuse
+1 here
On Thu, Jun 13, 2013 at 3:57 PM, Dmitry Soshnikov <
dmitry.soshni...@gmai
On Thu, Jun 13, 2013 at 2:38 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>
>> I personally don't see that there is any real conflict between
>> Object.mixin and a hypothetical "mixin" superclass combinator that someone
>> might define in the future.
>>
>
> What about multiple sources? That
Always-unstable is trivial: use a stable sort, and the first time you
encounter two elements that compare equal, swap them. The problem with
that is it isn't necessarily detectably unstable. The two elements you
swap might be equal in all ways. To be detectably unstable, you need
the sort function
On Thu, Jun 13, 2013 at 12:16 PM, Kevin Gadd wrote:
> I don't understand why you would intentionally sidetrack a discussion
> about a simple problem with academic details.
>
He brings up a very real point, which is that you can't realistically have
an "always unstable" sort. If I understand you
On Thu, Jun 13, 2013 at 5:38 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>
>> I personally don't see that there is any real conflict between
>> Object.mixin and a hypothetical "mixin" superclass combinator that someone
>> might define in the future.
>>
>
> What about multiple sources? That
Kevin Smith wrote:
Also, I misspoke earlier. The error is only if you *use* M.x, for the
same reason.
Ah - subtle but important point.
Yes, super-important in a growing independently-owned modules setting.
I.e., reality.
/be
___
es-disc
Just confirming: In ES1 days, the MS guy (Shon K.) suggested stability
but we all agreed not to require it, but I believe he implemented it.
This created a de-facto standard and SpiderMonkey and JSC matched.
I think V8 has a de-facto bug to fix. I'm ok with requiring stability as
a normative p
Allen Wirfs-Brock wrote:
I personally don't see that there is any real conflict between
Object.mixin and a hypothetical "mixin" superclass combinator that
someone might define in the future.
What about multiple sources? That might take almost all the perceived
conflict away.
/be
___
Le 13/06/2013 21:16, Kevin Gadd a écrit :
I have read the ES specs multiple times, and still accidentally
shipped an application that was broken by Array.sort's default
behavior in the wild. I know other people who have had the same
issues, and people who have read the spec and don't happen to
On Jun 13, 2013, at 10:09 AM, Kevin Smith wrote:
>
>
> Based on this and the example shown above, I think it's fair to say that
> reversing the arguments isn't in the ES6's best interest.
>
>
> Definitely. Reversing the argument order would make for awkward code like
> this:
>
> Objec
> M.x is the local variable, because otherwise changes in the exports of
> `"foo"` could, unbenknownst to M, cause an error.
>
>
I agree.
> Also, I misspoke earlier. The error is only if you *use* M.x, for the
> same reason.
>
Ah - subtle but important point.
{ Kevin }
M.x is the local variable, because otherwise changes in the exports of
`"foo"` could, unbenknownst to M, cause an error.
Also, I misspoke earlier. The error is only if you *use* M.x, for the
same reason.
Sam
On Thu, Jun 13, 2013 at 3:48 PM, Kevin Smith wrote:
> What about the following case?
>
What about the following case?
// M
export * from "foo";
export var x = 1;
// foo
export var x = 2;
Would M.x be bound to the local variable, or would this be an error as well?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozil
Woot! That's what I was hoping.
Thanks,
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This is a static error.
On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith wrote:
> Take the following situation:
>
> // M.js
> export * from "foo";
> export * from "bar";
>
> // "foo"
> export var x = 1;
>
> // "bar"
> export var x = 2;
>
> What is M.x bound to? foo.x (1),
On 6/13/13 at 12:24 PM, oli...@apple.com (Oliver Hunt) wrote:
I believe that the spec should mandate a stable sort, but i'm
not sure just how far we can go in trying to standardize exact
behavior of the sort without tying implementations to a single
implementation for all time.
One possibili
Take the following situation:
// M.js
export * from "foo";
export * from "bar";
// "foo"
export var x = 1;
// "bar"
export var x = 2;
What is M.x bound to? foo.x (1), bar.x (2), or is this an error? What is
our current thinking?
{ Kevin }
_
JSC switched to an always stable sort years ago due to compatibility problems
with content targeting firefox and IE depending on it.
We also had issues with inconsistent comparison functions, but i can't recall
exactly what the reasoning behind it was (nor the exact behavior we felt was
necessa
I have read the ES specs multiple times, and still accidentally shipped an
application that was broken by Array.sort's default behavior in the wild. I
know other people who have had the same issues, and people who have read
the spec and don't happen to have particular quirks defined in the spec
mem
While I like the name mixin, I infinitely like the name define more. Better
still I LOVE this
http://wiki.ecmascript.org/doku.php?id=strawman:define_properties_operator
On Thu, Jun 13, 2013 at 10:09 AM, Kevin Smith wrote:
>
>>
>> Based on this and the example shown above, I think it's fair to s
>
>
>
> Based on this and the example shown above, I think it's fair to say that
> reversing the arguments isn't in the ES6's best interest.
>
>
Definitely. Reversing the argument order would make for awkward code like
this:
Object.mixin({
a() {},
b: 123,
c
}, tar
On Thu, Jun 13, 2013 at 11:38 AM, Tobias Buschor
wrote:
> I propose to change the arguments.
>
> The second argument "target" is optional and default to
> "Object.create(null)"
>
This can already be achieved with Object.mixin(Object.create(null), source)
or if you've imported the dict module (or
On Thu, Jun 13, 2013 at 12:08 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> It seems es-discuss receives a lot of these emails, bikeshedding the
> behavior of `Object.mixin` from people with preconceived notions of what a
> "mixin" is and what a mixin function should do, how it shou
Le 13/06/2013 17:56, Kevin Gadd a écrit :
I don't really care about the precise language or semantics.
Maybe you should. In my opinion, that would certainly help having your
case better understood and heard.
I just don't want applications to break in the wild because an
Array.sort implementat
The fact it has been proposed as "mixin" method is a sign too ... is like
saying that `class` in JS is wrong because classical inheritance meant in
other language is not exactly the same in JS.
It would be nice to focus on the signature and finalize that in the spec
instead of raising every now an
Like I said, I don't care about the language or semantics. If it's such a
big problem for you to overlook the way I phrased it initially, I'll
rephrase it:
If a stable sort is used by the browser to implement Array.sort in some
scenarios, a stable sort should always be used to implement Array.sort
It seems es-discuss receives a lot of these emails, bikeshedding the behavior
of `Object.mixin` from people with preconceived notions of what a "mixin" is
and what a mixin function should do, how it should integrate with class syntax,
etc. In contrast, when it was just `Object.define`, it was ob
I don't really care about the precise language or semantics. I just don't
want applications to break in the wild because an Array.sort
implementation's stability changes based on the number of elements. That
feels like a much easier problem to solve than the problem of some browsers
being unstable
A real brain-bender for all those "extend" workalike users.
LHS, RHS assignment-expression order is best (Moto 68K vs. Intel 808x
asm wars; also gdb vs. binutils IIRC).
The lack of extensibility (or should we allow multiple sources now?) is
the killer for me.
/be
Tobias Buschor wrote:
I p
Even if stable sorts don't get required, it would make sense to require
that a given implementation is either always stable or always not stable.
The current situation with V8 seems likely to result in subtly broken
software shipping to the web, where it works in testing environments with
small amo
Bumping this old thread since V8 issue #90
(https://code.google.com/p/v8/issues/detail?id=90) has been getting lots of
comments lately.
It appears that unstable sort, while perfectly spec-compliant, doesn’t match
user expectations. It doesn’t help that some browsers/engines _do_ use a stable
s
Le 13 juin 2013 à 03:33, Brendan Eich a écrit :
> Andreas Rossberg wrote:
>> On 12 June 2013 23:27, Claude Pache wrote:
>>> Therefore, I think that "For/of coerces its argument to an iterator" is a
>>> wrong mental model, and "For/of accepts either a reusable iterable or a
>>> disposable iter
44 matches
Mail list logo
