Re: set.delete method name

[Brendan Eich]

Mark S. Miller wrote:
I appreciate the feedback, but I do not understand the rationale. Is 
it just to avoid needing to say


map['delete'](key)

when supporting old browsers without an ES5->ES3 translation step?


Yes. Isn't that enough friction? I think so based on long-standing pain 
that led us to unreserve keywords after dot.


I'm still open to remove because it's a better antonym to add. I do not 
think the base-level operator names (where they exist) must be re-used. 
But I may be missing a fine point here for why you prefer 'delete'?


/be


If there is no other downside, I'm inclined to stick with "delete".


On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon > wrote:


I agree that it should be named "remove" rather than delete.


On Tuesday, February 28, 2012, Yehuda Katz wrote:

Just catching up on this discussion. I should point out that
this problem applies to Map and possibly other collections as
well.

Speaking as someone who is looking to use these features
today, I hit this problem immediately. Ember.js already has a
Map; we can reliably generate a unique id for any object (by
stashing it on the object; ok for our cases), and have a
reliable way to generate guids for non-Objects.

Ideally, we'd like to be able to say something like:
`if(typeof Map !== "undefined") { Ember.Map = Map; }`
(although we'd probably do more checks because shims in
general have worse performance characteristics).

Unfortunately, because of the `delete` problem, we cannot do
this. Because we are unwilling to monkey-patch Map directly,
we will have to create a shim object that delegates to the Map.

I'm sympathetic to the "let's not make choices based on old
broken browsers", but let's be fair here. The name `remove` is
perfectly clear. In five years, nobody is going to think twice
about that API, and web developers won't think twice about it
today. Using a clear name that also happens not to run afoul
of older browsers for shim purposes isn't caving to the past:
it's being pragmatic about helping people adopt a new feature
with very little cost.

Yehuda Katz
(ph) 718.877.1325 



-- 
Adam Shannon

Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us

___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss




--
Cheers,
--MarkM
___
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

Re: Should "Literal" in syntactical grammar instead of lexical grammar?

[Brendan Eich]

程劭非 wrote:
> Thank you for the comments.
>
> There might be no normative significance but I mean there is no way to
> put the "Literal" production in a lexer. If a lexer produce token with
> type ”Literal“, syntactical parser will not be able to decide to use
> it as a ”Literal“ or a ”StringLiteral“.

Good point.

>
> So I think keeping this rule in current location might confuse the
> ones who want to implement this spec.

Agreed.

/be

>
> Thanks,
> Shaofei Cheng
>
> 2012/2/28 Brendan Eich mailto:bren...@mozilla.org>>
>
> Indeed this has come up before:
>
> https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html
>
> No one replied then, alas.
>
> There's no normative significance, as Michael Dyck conjectured. It
> seems we could move Literal. Perhaps Waldemar or Allen has a
> preference. At this point I am ok with letting the traditional
> location of Literal stand.
>
> /be
>
> 程劭非 wrote:
>
> Hi, everyone,
>
> I'm working a on ES parser recently and noticed something
> might be wrong about the symbol “Literal”.
>
> Since “Literal” and “StringLiteral" "NumericLiteral" appears
> in lexical grammar , I believe “Literal” should be a
> non-terminal symbol. Also there is no other rule using
> “Literal” in lexical grammar. As all above I think the
> following description is a syntactical grammar rule instead of
> a lexical grammar rule:
> /Literal /*::
> ***/NullLiteral/
>
> /BooleanLiteral
> NumericLiteral
> StringLiteral/
> /RegularExpressionLiteral/
>
>
> So my suggest is moving the description from Annex A.1 to
> Annex A.3
>
>
>
> Thanks,
> Shaofei Cheng
> ___
> 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: set.delete method name

[Adam Shannon]

I can easily see frameworks, a shim, or vendors widely adding code
such as the following.

Map.prototype.remove = function(elm) {
 this['delete'](elm);
};

Which should easily convince anyone that .remove() is better for the
end user than ['delete'](). Delete already has a meaning outside of
Maps or Sets, and is only introducing unneeded complexity to something
as simple as a Collection.

On Tue, Feb 28, 2012 at 18:22, Yehuda Katz  wrote:
> Let me explain my use-case a bit more. Ember exposes an Ember.Map class that
> downstream users (the framework, but also app developers) can use when they
> want maps with arbitrary keys. I explained the implementation a bit
> upthread.
>
> Ideally, I would like to be able to do something like Ember.Map = Map if ES6
> maps are available, since we fashioned our map API intentionally after the
> ES6 API.
>
> However, this means that all downstream users would need to use ['delete']
> something that is sufficiently weird and confusing to new developers that we
> always avoid it.
>
> It occurs to me that if Maps are available, so are proxies, but I'm not sure
> I want to start using proxies as a blunt force instrument.
>
> Sent from my Windows Phone
> 
> From: Mark S. Miller
> Sent: 2/28/2012 11:54 AM
> To: Adam Shannon
> Cc: Yehuda Katz; es-discuss
> Subject: Re: set.delete method name
>
> I appreciate the feedback, but I do not understand the rationale. Is it just
> to avoid needing to say
>
>     map['delete'](key)
>
> when supporting old browsers without an ES5->ES3 translation step? If there
> is no other downside, I'm inclined to stick with "delete".
>
>
> On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon  wrote:
>>
>> I agree that it should be named "remove" rather than delete.
>>
>>
>> On Tuesday, February 28, 2012, Yehuda Katz wrote:
>>>
>>> Just catching up on this discussion. I should point out that this problem
>>> applies to Map and possibly other collections as well.
>>>
>>> Speaking as someone who is looking to use these features today, I hit
>>> this problem immediately. Ember.js already has a Map; we can reliably
>>> generate a unique id for any object (by stashing it on the object; ok for
>>> our cases), and have a reliable way to generate guids for non-Objects.
>>>
>>> Ideally, we'd like to be able to say something like: `if(typeof Map !==
>>> "undefined") { Ember.Map = Map; }` (although we'd probably do more checks
>>> because shims in general have worse performance characteristics).
>>>
>>> Unfortunately, because of the `delete` problem, we cannot do this.
>>> Because we are unwilling to monkey-patch Map directly, we will have to
>>> create a shim object that delegates to the Map.
>>>
>>> I'm sympathetic to the "let's not make choices based on old broken
>>> browsers", but let's be fair here. The name `remove` is perfectly clear. In
>>> five years, nobody is going to think twice about that API, and web
>>> developers won't think twice about it today. Using a clear name that also
>>> happens not to run afoul of older browsers for shim purposes isn't caving to
>>> the past: it's being pragmatic about helping people adopt a new feature with
>>> very little cost.
>>>
>>> Yehuda Katz
>>> (ph) 718.877.1325
>>
>>
>>
>> --
>> Adam Shannon
>> Developer
>> University of Northern Iowa
>> Sophomore -- Computer Science B.S. & Mathematics
>> http://ashannon.us
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM



-- 
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: set.delete method name

[Yehuda Katz]

Let me explain my use-case a bit more. Ember exposes an Ember.Map class
that downstream users (the framework, but also app developers) can use when
they want maps with arbitrary keys. I explained the implementation a bit
upthread.

Ideally, I would like to be able to do something like Ember.Map = Map if
ES6 maps are available, since we fashioned our map API intentionally after
the ES6 API.

However, this means that all downstream users would need to use ['delete']
something that is sufficiently weird and confusing to new developers that
we always avoid it.

It occurs to me that if Maps are available, so are proxies, but I'm not
sure I want to start using proxies as a blunt force instrument.

Sent from my Windows Phone
--
From: Mark S. Miller
Sent: 2/28/2012 11:54 AM
To: Adam Shannon
Cc: Yehuda Katz; es-discuss
Subject: Re: set.delete method name

I appreciate the feedback, but I do not understand the rationale. Is it
just to avoid needing to say

map['delete'](key)

when supporting old browsers without an ES5->ES3 translation step? If there
is no other downside, I'm inclined to stick with "delete".


On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon  wrote:

> I agree that it should be named "remove" rather than delete.
>
>
> On Tuesday, February 28, 2012, Yehuda Katz wrote:
>
>> Just catching up on this discussion. I should point out that this problem
>> applies to Map and possibly other collections as well.
>>
>> Speaking as someone who is looking to use these features today, I hit
>> this problem immediately. Ember.js already has a Map; we can reliably
>> generate a unique id for any object (by stashing it on the object; ok for
>> our cases), and have a reliable way to generate guids for non-Objects.
>>
>> Ideally, we'd like to be able to say something like: `if(typeof Map !==
>> "undefined") { Ember.Map = Map; }` (although we'd probably do more checks
>> because shims in general have worse performance characteristics).
>>
>> Unfortunately, because of the `delete` problem, we cannot do this.
>> Because we are unwilling to monkey-patch Map directly, we will have to
>> create a shim object that delegates to the Map.
>>
>>  I'm sympathetic to the "let's not make choices based on old broken
>> browsers", but let's be fair here. The name `remove` is perfectly clear. In
>> five years, nobody is going to think twice about that API, and web
>> developers won't think twice about it today. Using a clear name that also
>> happens not to run afoul of older browsers for shim purposes isn't caving
>> to the past: it's being pragmatic about helping people adopt a new feature
>> with very little cost.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>
>
> --
> Adam Shannon
> Developer
> University of Northern Iowa
> Sophomore -- Computer Science B.S. & Mathematics
> http://ashannon.us
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Typeof this in getters (was: eval on non-strings)

[Domenic Denicola]

> To clarify, the expected results here are:
> 
> Non-strict
> Typeof this inside a function when called on a number: object
> Typeof this inside an Object.prototype getter when used on a number: object
>
> Strict
> Typeof this inside a function when called on a number: number
> Typeof this inside an Object.prototype getter when used on a number: number
>
> right?

Yes.

> There’s over a hundred test cases that have already been created, and will be 
> contributed ‘soon’ to cover https://bugs.ecmascript.org/show_bug.cgi?id=180.  
> One such test case is:
>  function foo()
>  {
>    'use strict';
>    return typeof(this);
>  }
>  function bar()
>  {
>    return typeof(this);
>  }
>  return foo.call(1) === 'number' && bar.call(1) === 'object';

Chrome fails this one with `bar.call(1)==='number'`, but everyone else passes.

> Another that seem relevant here is:
> function testcase() {
> var o = {};
> Object.defineProperty(o, "foo", { get: function() { "use strict"; return 
> this; } });
> return o.foo===o;
> }

This is irrelevant because it is not testing primitives and boxing. (More 
formally, it is not testing the relevant part of 10.4.3 that we are discussing.)

> On that note, is there anything that’s particularly interesting spec-wise in 
> defining foo on Object.prototype instead of a generic object and validating 
> there? 

It's relevant because it allows use on numbers, i.e. `(0).getMe`. The same 
results happen if you define on `Number.prototype`.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Typeof this in getters (was: eval on non-strings)

[Dave Fugate]

To clarify, the expected results here are:
Non-strict
Typeof this inside a function when called on a number: object
Typeof this inside an Object.prototype getter when used on a number: object
Strict
Typeof this inside a function when called on a number: number
Typeof this inside an Object.prototype getter when used on a number: number
right?

There's over a hundred test cases that have already been created, and will be 
contributed 'soon' to cover https://bugs.ecmascript.org/show_bug.cgi?id=180.  
One such test case is:
  function foo()
  {
'use strict';
return typeof(this);
  }
  function bar()
  {
return typeof(this);
  }
  return foo.call(1) === 'number' && bar.call(1) === 'object';


Another that seem relevant here is:
function testcase() {
var o = {};
Object.defineProperty(o, "foo", { get: function() { "use strict"; return this; 
} });
return o.foo===o;
}
On that note, is there anything that's particularly interesting spec-wise in 
defining foo on Object.prototype instead of a generic object and validating 
there?

Thanks!

Dave

From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On 
Behalf Of Mark S. Miller
Sent: Tuesday, February 28, 2012 3:45 PM
To: Domenic Denicola
Cc: es-discuss@mozilla.org; Brendan Eich
Subject: Re: Typeof this in getters (was: eval on non-strings)


On Tue, Feb 28, 2012 at 3:38 PM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:
Both IE10 Developer Preview (10.0.8102.0) and IE10 Platform Preview 4 
(10.0.8103.0) output

   number  object
   objectobject

We'll see if tomorrow's drop does any better.

Sounds like I should file test262 bugs as well.

Oops. I meant for

Yes, thanks!

to be placed here. Yes, thanks for filing test262 bugs as well.



From: Mark S. Miller [mailto:erig...@google.com]
Sent: Tuesday, February 28, 2012 14:38
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Brendan Eich; 
es-discuss@mozilla.org
Subject: Re: Typeof this in getters (was: eval on non-strings)

I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I just 
tried it on very recent versions of 4 or the 5 major browsers. I was shocked to 
see that all of them were wrong.

Correct would be

number  number
objectobject

Chrome 19 gave

number  number
objectnumber

Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF Nightly 13 
all gave

number  object
objectobject

What does the latest IE10 preview do?

Domenic, as you post bugs against the browsers, please send me the URLs. Thanks.


On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:
> Specifically regarding ToObject.  It's use is important in minimizing the 
> semantic differences between primitive values and Objects. In ES5 we 
> eliminated the automatic wrapping of primitive values  used as this values in 
> method invocations.  That means that in most cases 42 and (new Number(42)) 
> can be used interchangeably. If we start leaving out ToObject calls in random 
> places the distinction between a primitive value and a wrapped primitive 
> values will start tripping people up.

This actually is apropos of something I'd been meaning to ask about. Consider 
the following JSFiddle:

http://jsfiddle.net/CxdMs/15/

It seems reasonably clear that the result for functions should be object 
(non-strict)/number (strict), according to section 10.4.3.

But for getters, the major browsers disagree, and my spec-fu can't find 
anything besides the abovementioned section. Firefox and IE9 say object/object, 
while V8 says number/number. And at least one version of JavaScriptCore we have 
lying around says number/object. If someone could walk me through the spec 
correctly, I'd be happy to file appropriate browser bugs.

Note that this is a real-world issue. The Chai.js assertion library is trying 
to break free of V8 and become useful in browsers, but is encountering problems 
due to this behavior:

https://github.com/logicalparadox/chai/issues/32

Thanks all,
Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




--
Cheers,
--MarkM



--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Mark S. Miller]

On Tue, Feb 28, 2012 at 3:38 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> Both IE10 Developer Preview (10.0.8102.0) and IE10 Platform Preview 4
> (10.0.8103.0) output
>
>number  object
>objectobject
>
> We'll see if tomorrow's drop does any better.
>
> Sounds like I should file test262 bugs as well.
>

Oops. I meant for

Yes, thanks!

to be placed here. Yes, thanks for filing test262 bugs as well.



>
> From: Mark S. Miller [mailto:erig...@google.com]
> Sent: Tuesday, February 28, 2012 14:38
> To: Domenic Denicola
> Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org
> Subject: Re: Typeof this in getters (was: eval on non-strings)
>
> I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better.
> I just tried it on very recent versions of 4 or the 5 major browsers. I was
> shocked to see that all of them were wrong.
>
> Correct would be
>
> number  number
> objectobject
>
> Chrome 19 gave
>
> number  number
> objectnumber
>
> Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF
> Nightly 13 all gave
>
> number  object
> objectobject
>
> What does the latest IE10 preview do?
>
> Domenic, as you post bugs against the browsers, please send me the URLs.
> Thanks.
>
>
> On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
> > Specifically regarding ToObject.  It's use is important in minimizing
> the semantic differences between primitive values and Objects. In ES5 we
> eliminated the automatic wrapping of primitive values  used as this values
> in method invocations.  That means that in most cases 42 and (new
> Number(42)) can be used interchangeably. If we start leaving out ToObject
> calls in random places the distinction between a primitive value and a
> wrapped primitive values will start tripping people up.
>
> This actually is apropos of something I'd been meaning to ask about.
> Consider the following JSFiddle:
>
> http://jsfiddle.net/CxdMs/15/
>
> It seems reasonably clear that the result for functions should be object
> (non-strict)/number (strict), according to section 10.4.3.
>
> But for getters, the major browsers disagree, and my spec-fu can't find
> anything besides the abovementioned section. Firefox and IE9 say
> object/object, while V8 says number/number. And at least one version of
> JavaScriptCore we have lying around says number/object. If someone could
> walk me through the spec correctly, I'd be happy to file appropriate
> browser bugs.
>
> Note that this is a real-world issue. The Chai.js assertion library is
> trying to break free of V8 and become useful in browsers, but is
> encountering problems due to this behavior:
>
> https://github.com/logicalparadox/chai/issues/32
>
> Thanks all,
> Domenic
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Cheers,
> --MarkM
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Mark S. Miller]

On Tue, Feb 28, 2012 at 3:38 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> Both IE10 Developer Preview (10.0.8102.0) and IE10 Platform Preview 4
> (10.0.8103.0) output
>
>number  object
>objectobject
>
> We'll see if tomorrow's drop does any better.
>

yes, thanks!



>
> Sounds like I should file test262 bugs as well.
>
> From: Mark S. Miller [mailto:erig...@google.com]
> Sent: Tuesday, February 28, 2012 14:38
> To: Domenic Denicola
> Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org
> Subject: Re: Typeof this in getters (was: eval on non-strings)
>
> I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better.
> I just tried it on very recent versions of 4 or the 5 major browsers. I was
> shocked to see that all of them were wrong.
>
> Correct would be
>
> number  number
> objectobject
>
> Chrome 19 gave
>
> number  number
> objectnumber
>
> Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF
> Nightly 13 all gave
>
> number  object
> objectobject
>
> What does the latest IE10 preview do?
>
> Domenic, as you post bugs against the browsers, please send me the URLs.
> Thanks.
>
>
> On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
> > Specifically regarding ToObject.  It's use is important in minimizing
> the semantic differences between primitive values and Objects. In ES5 we
> eliminated the automatic wrapping of primitive values  used as this values
> in method invocations.  That means that in most cases 42 and (new
> Number(42)) can be used interchangeably. If we start leaving out ToObject
> calls in random places the distinction between a primitive value and a
> wrapped primitive values will start tripping people up.
>
> This actually is apropos of something I'd been meaning to ask about.
> Consider the following JSFiddle:
>
> http://jsfiddle.net/CxdMs/15/
>
> It seems reasonably clear that the result for functions should be object
> (non-strict)/number (strict), according to section 10.4.3.
>
> But for getters, the major browsers disagree, and my spec-fu can't find
> anything besides the abovementioned section. Firefox and IE9 say
> object/object, while V8 says number/number. And at least one version of
> JavaScriptCore we have lying around says number/object. If someone could
> walk me through the spec correctly, I'd be happy to file appropriate
> browser bugs.
>
> Note that this is a real-world issue. The Chai.js assertion library is
> trying to break free of V8 and become useful in browsers, but is
> encountering problems due to this behavior:
>
> https://github.com/logicalparadox/chai/issues/32
>
> Thanks all,
> Domenic
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Cheers,
> --MarkM
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Typeof this in getters (was: eval on non-strings)

[Domenic Denicola]

Both IE10 Developer Preview (10.0.8102.0) and IE10 Platform Preview 4 
(10.0.8103.0) output

number  object
objectobject

We'll see if tomorrow's drop does any better.

Sounds like I should file test262 bugs as well.

From: Mark S. Miller [mailto:erig...@google.com] 
Sent: Tuesday, February 28, 2012 14:38
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org
Subject: Re: Typeof this in getters (was: eval on non-strings)

I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I just 
tried it on very recent versions of 4 or the 5 major browsers. I was shocked to 
see that all of them were wrong.

Correct would be

    number      number
    object        object

Chrome 19 gave

    number      number
    object        number

Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF Nightly 13 
all gave

    number      object
    object        object

What does the latest IE10 preview do?

Domenic, as you post bugs against the browsers, please send me the URLs. Thanks.


On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola 
 wrote:
> Specifically regarding ToObject.  It's use is important in minimizing the 
> semantic differences between primitive values and Objects. In ES5 we 
> eliminated the automatic wrapping of primitive values  used as this values in 
> method invocations.  That means that in most cases 42 and (new Number(42)) 
> can be used interchangeably. If we start leaving out ToObject calls in random 
> places the distinction between a primitive value and a wrapped primitive 
> values will start tripping people up.

This actually is apropos of something I'd been meaning to ask about. Consider 
the following JSFiddle:

http://jsfiddle.net/CxdMs/15/

It seems reasonably clear that the result for functions should be object 
(non-strict)/number (strict), according to section 10.4.3.

But for getters, the major browsers disagree, and my spec-fu can't find 
anything besides the abovementioned section. Firefox and IE9 say object/object, 
while V8 says number/number. And at least one version of JavaScriptCore we have 
lying around says number/object. If someone could walk me through the spec 
correctly, I'd be happy to file appropriate browser bugs.

Note that this is a real-world issue. The Chai.js assertion library is trying 
to break free of V8 and become useful in browsers, but is encountering problems 
due to this behavior:

https://github.com/logicalparadox/chai/issues/32

Thanks all,
Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Mark S. Miller]

On Tue, Feb 28, 2012 at 2:18 PM, Allen Wirfs-Brock wrote:

>
> On Feb 28, 2012, at 9:20 AM, Mark S. Miller wrote:
>
> On Tue, Feb 28, 2012 at 7:54 AM, Allen Wirfs-Brock 
> wrote:
> [...]
>
>> There is also a matter of maintaining internal insistency within a
>> language. [...] JS generally converts primitive values to wrapper objects
>> whenever one is used in a context that requires an object. [...]
>
>
> Some other violations of this rule that surprised me when I first came
> across them:
>
>  > 3 instanceof Number
> false
> > 'x' in 3
> TypeError: Cannot use 'in' operator to search for 'x' in 3
>
>
> I am not suggesting that we do anything to repair these -- it is likely
> too late. But depending on how many other such irregularities there are, it
> may not altogether be clear which direction the principle of least surprise
> should take us.
>
>
> Both of these were added to the spec. in ES3.  They are probably exactly
> the sort of thing I was warning against when I mentioned point in time or
> spec. writer  introduced inconsistencies.  Since exceptions were also
> spec'ed in ES3 I bet whoever spec'ed in and instanceof thought that
> throwing would be the "right thing" and perhaps didn't even think about
> maintaining consistency with the language's legacy.  who knows...
>
> Since, in and instanceof currently throw in the above situations we
> probably could get away with changing them to do ToObject.  Not necessarily
> saying we should, but it probably wouldn't break anything.  It would be a
> set towards  maintaining internal consistency.
>

Fixing "in" would be be great if we can. But the "instanceof" example above
correctly does not throw, it returns false, which we should assume we
cannot fix. "instanceof" does throw if its *right* operand is not an object
with a [[HasInstance]] method. Is that the case you have in mind?

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Allen Wirfs-Brock]

On Feb 28, 2012, at 9:20 AM, Mark S. Miller wrote:

> On Tue, Feb 28, 2012 at 7:54 AM, Allen Wirfs-Brock  
> wrote:
> [...]
> There is also a matter of maintaining internal insistency within a language. 
> [...] JS generally converts primitive values to wrapper objects whenever one 
> is used in a context that requires an object. [...]
> 
> Some other violations of this rule that surprised me when I first came across 
> them:
> 
> 
> > 3 instanceof Number
> 
> false
> 
> > 'x' in 3
> 
> TypeError: Cannot use 'in' operator to search for 'x' in 3
>  
> I am not suggesting that we do anything to repair these -- it is likely too 
> late. But depending on how many other such irregularities there are, it may 
> not altogether be clear which direction the principle of least surprise 
> should take us.

Both of these were added to the spec. in ES3.  They are probably exactly the 
sort of thing I was warning against when I mentioned point in time or spec. 
writer  introduced inconsistencies.  Since exceptions were also spec'ed in ES3 
I bet whoever spec'ed in and instanceof thought that throwing would be the 
"right thing" and perhaps didn't even think about maintaining consistency with 
the language's legacy.  who knows...

Since, in and instanceof currently throw in the above situations we probably 
could get away with changing them to do ToObject.  Not necessarily saying we 
should, but it probably wouldn't break anything.  It would be a set towards  
maintaining internal consistency. 

 
Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Allen Wirfs-Brock]

On Feb 28, 2012, at 10:03 AM, Domenic Denicola wrote:

>> Specifically regarding ToObject.  It's use is important in minimizing the 
>> semantic differences between primitive values and Objects. In ES5 we 
>> eliminated the automatic wrapping of primitive values  used as this values 
>> in method invocations.  That means that in most cases 42 and (new 
>> Number(42)) can be used interchangeably. If we start leaving out ToObject 
>> calls in random places the distinction between a primitive value and a 
>> wrapped primitive values will start tripping people up.
> 
> This actually is apropos of something I'd been meaning to ask about. Consider 
> the following JSFiddle:
> 
> http://jsfiddle.net/CxdMs/15/
> 
> It seems reasonably clear that the result for functions should be object 
> (non-strict)/number (strict), according to section 10.4.3.

10.4.3 is the applicable section.  It get/set function is still "function code" 
so it doesn't matter what mechanism was used to call it.  It still has to pass 
through the 10.4.3 requirements.  So the correct answer is number/object.

Any other answer is not in conformance with the spec.  

There there should be test262 tests for this.  However I bet there aren't any, 
given that the two major contributors to the test suite appear to be out of 
conformance

Allen





> 
> But for getters, the major browsers disagree, and my spec-fu can't find 
> anything besides the abovementioned section. Firefox and IE9 say 
> object/object, while V8 says number/number. And at least one version of 
> JavaScriptCore we have lying around says number/object. If someone could walk 
> me through the spec correctly, I'd be happy to file appropriate browser bugs.
> 
> Note that this is a real-world issue. The Chai.js assertion library is trying 
> to break free of V8 and become useful in browsers, but is encountering 
> problems due to this behavior:
> 
> https://github.com/logicalparadox/chai/issues/32
> 
> Thanks all,
> Domenic
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Rick Waldron]

On Tue, Feb 28, 2012 at 2:42 PM, Oliver Hunt  wrote:

>
> On Feb 28, 2012, at 11:38 AM, Mark S. Miller wrote:
>
> I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better.
> I just tried it on very recent versions of 4 or the 5 major browsers. I was
> shocked to see that all of them were wrong.
>
> Correct would be
>
> number  number
> objectobject
>
>
I went to refresh myself on this and thought others might be interested in
reading the same: http://es5.github.com/#this-Number-value


>
> Chrome 19 gave
>
> number  number
> objectnumber
>
> Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF
> Nightly 13 all gave
>
> number  object
> objectobject
>
>
> We consider this a bug in JSC, in the great "make |this| correct"
> refactoring of 2011 we missed the getter/setter entries manually performing
> this conversion prior to calling the function proper...
>
> --Oliver
>
>
> ___
> 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

RE: set.delete method name

[Xavier MONTILLET]

I don't think we should care about old brosers when building ES 6. People
won't use just one part of it. They'll use all of it or just stick with ES
5/3.

Plus there will be transpilers and replacing ".delete" by "['delete']"
isn't hard...

Sent from my smartphone.
On Feb 28, 2012 8:59 PM, "Domenic Denicola" 
wrote:

> > I appreciate the feedback, but I do not understand the rationale.
>
> The rationale I found compelling from upthread was that "remove" is a more
> apt antonym to "add".
>
> To compare, "delete"'s natural counterpart would be "put".
> ___
> 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

RE: set.delete method name

[Domenic Denicola]

> I appreciate the feedback, but I do not understand the rationale.

The rationale I found compelling from upthread was that "remove" is a more apt 
antonym to "add".

To compare, "delete"'s natural counterpart would be "put".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: set.delete method name

[Mark S. Miller]

I appreciate the feedback, but I do not understand the rationale. Is it
just to avoid needing to say

map['delete'](key)

when supporting old browsers without an ES5->ES3 translation step? If there
is no other downside, I'm inclined to stick with "delete".


On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon  wrote:

> I agree that it should be named "remove" rather than delete.
>
>
> On Tuesday, February 28, 2012, Yehuda Katz wrote:
>
>> Just catching up on this discussion. I should point out that this problem
>> applies to Map and possibly other collections as well.
>>
>> Speaking as someone who is looking to use these features today, I hit
>> this problem immediately. Ember.js already has a Map; we can reliably
>> generate a unique id for any object (by stashing it on the object; ok for
>> our cases), and have a reliable way to generate guids for non-Objects.
>>
>> Ideally, we'd like to be able to say something like: `if(typeof Map !==
>> "undefined") { Ember.Map = Map; }` (although we'd probably do more checks
>> because shims in general have worse performance characteristics).
>>
>> Unfortunately, because of the `delete` problem, we cannot do this.
>> Because we are unwilling to monkey-patch Map directly, we will have to
>> create a shim object that delegates to the Map.
>>
>>  I'm sympathetic to the "let's not make choices based on old broken
>> browsers", but let's be fair here. The name `remove` is perfectly clear. In
>> five years, nobody is going to think twice about that API, and web
>> developers won't think twice about it today. Using a clear name that also
>> happens not to run afoul of older browsers for shim purposes isn't caving
>> to the past: it's being pragmatic about helping people adopt a new feature
>> with very little cost.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>
>
> --
> Adam Shannon
> Developer
> University of Northern Iowa
> Sophomore -- Computer Science B.S. & Mathematics
> http://ashannon.us
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: set.delete method name

[Adam Shannon]

I agree that it should be named "remove" rather than delete.

On Tuesday, February 28, 2012, Yehuda Katz wrote:

> Just catching up on this discussion. I should point out that this problem
> applies to Map and possibly other collections as well.
>
> Speaking as someone who is looking to use these features today, I hit this
> problem immediately. Ember.js already has a Map; we can reliably generate a
> unique id for any object (by stashing it on the object; ok for our cases),
> and have a reliable way to generate guids for non-Objects.
>
> Ideally, we'd like to be able to say something like: `if(typeof Map !==
> "undefined") { Ember.Map = Map; }` (although we'd probably do more checks
> because shims in general have worse performance characteristics).
>
> Unfortunately, because of the `delete` problem, we cannot do this. Because
> we are unwilling to monkey-patch Map directly, we will have to create a
> shim object that delegates to the Map.
>
>  I'm sympathetic to the "let's not make choices based on old broken
> browsers", but let's be fair here. The name `remove` is perfectly clear. In
> five years, nobody is going to think twice about that API, and web
> developers won't think twice about it today. Using a clear name that also
> happens not to run afoul of older browsers for shim purposes isn't caving
> to the past: it's being pragmatic about helping people adopt a new feature
> with very little cost.
>
> Yehuda Katz
> (ph) 718.877.1325
>


-- 
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Oliver Hunt]

On Feb 28, 2012, at 11:38 AM, Mark S. Miller wrote:

> I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I 
> just tried it on very recent versions of 4 or the 5 major browsers. I was 
> shocked to see that all of them were wrong.
> 
> Correct would be
> 
> number  number
> objectobject
> 
> Chrome 19 gave
> 
> number  number
> objectnumber
> 
> Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF Nightly 
> 13 all gave
> 
> number  object
> objectobject

We consider this a bug in JSC, in the great "make |this| correct" refactoring 
of 2011 we missed the getter/setter entries manually performing this conversion 
prior to calling the function proper...

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Typeof this in getters (was: eval on non-strings)

[Mark S. Miller]

I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I
just tried it on very recent versions of 4 or the 5 major browsers. I was
shocked to see that all of them were wrong.

Correct would be

number  number
objectobject

Chrome 19 gave

number  number
objectnumber

Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF Nightly
13 all gave

number  object
objectobject

What does the latest IE10 preview do?

Domenic, as you post bugs against the browsers, please send me the URLs.
Thanks.


On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> > Specifically regarding ToObject.  It's use is important in minimizing
> the semantic differences between primitive values and Objects. In ES5 we
> eliminated the automatic wrapping of primitive values  used as this values
> in method invocations.  That means that in most cases 42 and (new
> Number(42)) can be used interchangeably. If we start leaving out ToObject
> calls in random places the distinction between a primitive value and a
> wrapped primitive values will start tripping people up.
>
> This actually is apropos of something I'd been meaning to ask about.
> Consider the following JSFiddle:
>
> http://jsfiddle.net/CxdMs/15/
>
> It seems reasonably clear that the result for functions should be object
> (non-strict)/number (strict), according to section 10.4.3.
>
> But for getters, the major browsers disagree, and my spec-fu can't find
> anything besides the abovementioned section. Firefox and IE9 say
> object/object, while V8 says number/number. And at least one version of
> JavaScriptCore we have lying around says number/object. If someone could
> walk me through the spec correctly, I'd be happy to file appropriate
> browser bugs.
>
> Note that this is a real-world issue. The Chai.js assertion library is
> trying to break free of V8 and become useful in browsers, but is
> encountering problems due to this behavior:
>
> https://github.com/logicalparadox/chai/issues/32
>
> Thanks all,
> Domenic
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Typeof this in getters (was: eval on non-strings)

[Domenic Denicola]

> Specifically regarding ToObject.  It's use is important in minimizing the 
> semantic differences between primitive values and Objects. In ES5 we 
> eliminated the automatic wrapping of primitive values  used as this values in 
> method invocations.  That means that in most cases 42 and (new Number(42)) 
> can be used interchangeably. If we start leaving out ToObject calls in random 
> places the distinction between a primitive value and a wrapped primitive 
> values will start tripping people up.

This actually is apropos of something I'd been meaning to ask about. Consider 
the following JSFiddle:

http://jsfiddle.net/CxdMs/15/

It seems reasonably clear that the result for functions should be object 
(non-strict)/number (strict), according to section 10.4.3.

But for getters, the major browsers disagree, and my spec-fu can't find 
anything besides the abovementioned section. Firefox and IE9 say object/object, 
while V8 says number/number. And at least one version of JavaScriptCore we have 
lying around says number/object. If someone could walk me through the spec 
correctly, I'd be happy to file appropriate browser bugs.

Note that this is a real-world issue. The Chai.js assertion library is trying 
to break free of V8 and become useful in browsers, but is encountering problems 
due to this behavior:

https://github.com/logicalparadox/chai/issues/32

Thanks all,
Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Second arguments for Array.prototype.sort: map function

[Mark S. Miller]

On Tue, Feb 28, 2012 at 3:05 AM, Brendan Eich  wrote:

> Yes, clear enough -- however adding new trailing arguments to an existing
> method is treacherous. It's likely calls in the wild pass a second argument
> by mistake. Less likely but still possible: an implementation has unwisely
> extended sort to have an optional second parameter already. This goes
> against the now-explicit NOTE in ES5:
>
> NOTE Implementations that add additional capabilities to the set of
> built-in functions are encouraged to do so by adding new functions rather
> than adding new parameters to existing functions.
>
> We could rule this out for the top five browser engines, but the
> possibility of extant code passing an extra actual parameter remains.
>

Why rule this out? IIRC, the rationale is that JS code is generally
encouraged to use "feature detection" style to attempt to detect presence
of new or optional functionality. The encouraged styles I've seen are
* if ('methodName' in obj)...
* if (obj.methodName)...
* if (typeof obj.methodName === 'function')...

I have not seen people "&&" these with a check of "obj.methodName.length
=== expectedArity". I would prefer to avoid encouraging such an additional
check -- especially as function arity has historically been unreliable as
an indicator of anything.


>
> Better to have a new sortWithTransform method if necessary.


If necessary, sure. This one doesn't seem so IMO.



>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Math.clz()

[Jussi Kalliokoski]

We're working on JS audio decoders, and one huge performance issue atm is
clz() [count leading zeroes], which is a very commonly used algorithm in
decoders. We've tried several different approaches and benchmarked them
[1], however, different approaches work better on different engines, so
optimizing the function is a bit of a no-go, especially if we want to have
it fast in the future as well.

So, I thought I'd propose something that would go well with the earlier
proposals to extend Math [2]:

Math.clz(number)

This would allow for great speed boost in our decoders if it the JS engine
had this built-in and optimized.

While at it, it might be wise to add other related functions as well, such
as clo (count leading ones), although not as useful.

Cheers,
Jussi

[1]: http://jsperf.com/read-leading-zeros/8
[2]: http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array extras functionality for iterators

[Rick Waldron]

On Tue, Feb 28, 2012 at 12:06 PM, Yehuda Katz  wrote:

> Catching up on this discussion.
>
> Personally, I'd like to see us come to quick consensus on `forEach` for
> collections, because without something like `forEach`, it's impossible to
> implement useful versions of these collections in user-space in browsers
> that do not implement for-of.
>
> Indeed, the current browsers that implement Map and Set do not implement
> for-of, which means that even though browsers implement the collections
> (and Mozilla has for a bit now), they are not very useful because they
> cannot be iterated over. Had `forEach` been part of the initial spec, I
> would be using them today.
>

I've had the same experience that Yehuda describes - it's almost comical
that Chrome blog published an announcement for the support of Map and Set,
beyond...

> var s = new Set()
"undefined"
> s.add("foo")
"undefined"
> s.has("foo")
true
> s.delete("foo")
"undefined"

...They are useless.



>
> One last thing: `forEach` on `Map` should probably pass the key and value
> to the function.
>

+1 to Map.prototype.forEach receiving key and value as arguments


>
> Yehuda Katz
> (ph) 718.877.1325
>
> ___
> 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

Re: eval on non-strings

[Mark S. Miller]

On Tue, Feb 28, 2012 at 7:54 AM, Allen Wirfs-Brock wrote:
[...]

> There is also a matter of maintaining internal insistency within a
> language. [...] JS generally converts primitive values to wrapper objects
> whenever one is used in a context that requires an object. [...]


Some other violations of this rule that surprised me when I first came
across them:

> 3 instanceof Number
false
> 'x' in 3
TypeError: Cannot use 'in' operator to search for 'x' in 3


I am not suggesting that we do anything to repair these -- it is likely too
late. But depending on how many other such irregularities there are, it may
not altogether be clear which direction the principle of least surprise
should take us.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Array extras functionality for iterators

[Yehuda Katz]

Catching up on this discussion.

Personally, I'd like to see us come to quick consensus on `forEach` for
collections, because without something like `forEach`, it's impossible to
implement useful versions of these collections in user-space in browsers
that do not implement for-of.

Indeed, the current browsers that implement Map and Set do not implement
for-of, which means that even though browsers implement the collections
(and Mozilla has for a bit now), they are not very useful because they
cannot be iterated over. Had `forEach` been part of the initial spec, I
would be using them today.

One last thing: `forEach` on `Map` should probably pass the key and value
to the function.

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "Literal" in syntactical grammar instead of lexical grammar?

[程劭非]

Thank you, Allen.

I've checked ES6 draft and reported a bug. see
https://bugs.ecmascript.org/show_bug.cgi?id=281

2012/2/29 Allen Wirfs-Brock 

> Yes, Literal could be moved to the syntactic grammar. There is already
> some grammar refactoring like this going on in the Es6 draft.
>
> The best way to capture these sorts of editorial issues is to file a bug
> using bugs.ecmascript.org against the current Es6 draft.
>
> Allen
>
>
>
>
> On Feb 28, 2012, at 2:50 AM, Brendan Eich wrote:
>
> Indeed this has come up before:
>
> https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html
>
> No one replied then, alas.
>
> There's no normative significance, as Michael Dyck conjectured. It seems
> we could move Literal. Perhaps Waldemar or Allen has a preference. At this
> point I am ok with letting the traditional location of Literal stand.
>
> /be
>
> 程劭非 wrote:
>
> Hi, everyone,
>
>
> I'm working a on ES parser recently and noticed something might be wrong
> about the symbol “Literal”.
>
>
> Since “Literal” and “StringLiteral" "NumericLiteral" appears in lexical
> grammar , I believe “Literal” should be a non-terminal symbol. Also there
> is no other rule using “Literal” in lexical grammar. As all above I think
> the following description is a syntactical grammar rule instead of a
> lexical grammar rule:
>
> /Literal /*::
>
> ***/NullLiteral/
>
>
> /BooleanLiteral
>
> NumericLiteral
>
> StringLiteral/
>
> /RegularExpressionLiteral/
>
>
> So my suggest is moving the description from Annex A.1 to Annex A.3
>
>
>
>
> Thanks,
>
> Shaofei Cheng
>
> ___
>
> 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
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: set.delete method name

[Yehuda Katz]

Just catching up on this discussion. I should point out that this problem
applies to Map and possibly other collections as well.

Speaking as someone who is looking to use these features today, I hit this
problem immediately. Ember.js already has a Map; we can reliably generate a
unique id for any object (by stashing it on the object; ok for our cases),
and have a reliable way to generate guids for non-Objects.

Ideally, we'd like to be able to say something like: `if(typeof Map !==
"undefined") { Ember.Map = Map; }` (although we'd probably do more checks
because shims in general have worse performance characteristics).

Unfortunately, because of the `delete` problem, we cannot do this. Because
we are unwilling to monkey-patch Map directly, we will have to create a
shim object that delegates to the Map.

I'm sympathetic to the "let's not make choices based on old broken
browsers", but let's be fair here. The name `remove` is perfectly clear. In
five years, nobody is going to think twice about that API, and web
developers won't think twice about it today. Using a clear name that also
happens not to run afoul of older browsers for shim purposes isn't caving
to the past: it's being pragmatic about helping people adopt a new feature
with very little cost.

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Andreas Rossberg]

On 28 February 2012 16:54, Allen Wirfs-Brock  wrote:
> There is also a matter of maintaining internal insistency within a language.  
> A language that consistently treats a common situation the say way everyplace 
> it occurs is going to be easier to learn and feels more coherent than one 
> that has contextually different behavior for the same situations. JS 
> generally converts primitive values to wrapper objects whenever one is used 
> in a context that requires an object.  If we start throwing exceptions in new 
> feature contexts that require an object we are making the language less 
> internally consistent. We should want to avoid that situation.
>
> Individual features shouldn't differ in common detail just because they were 
> designed at different points in time or were defined by different people.  
> These sorts of inconsistency are pretty easy to spot at the level of the code 
> patterns used in the specification algorithms.  When I see deviations of this 
> sort in proposal that I'm incorporating into the spec. I generally just fix 
> them.
>
> Specifically regarding ToObject.  It's use is important in minimizing the 
> semantic differences between primitive values and Objects. In ES5 we 
> eliminated the automatic wrapping of primitive values  used as this values in 
> method invocations.  That means that in most cases 42 and (new Number(42)) 
> can be used interchangeably. If we start leaving out ToObject calls in random 
> places the distinction between a primitive value and a wrapped primitive 
> values will start tripping people up.


While I agree with this principle in general, the wider angle is that
it is just an instance of the Principle of Least Surprise. And that
can be a little bit more complicated. Last time round, all JS
programmers on which I tested the idea of "let [x, y] = 0" not
throwing were *very* surprised (outraged is a more accurate
description in some cases).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "Literal" in syntactical grammar instead of lexical grammar?

[程劭非]

Thank you for the comments.

There might be no normative significance but I mean there is no way to put
the "Literal" production in a lexer.  If a lexer produce token with type
”Literal“, syntactical parser will not be able to decide to use it as a
”Literal“ or a ”StringLiteral“.

So I think keeping this rule in current location might confuse the ones who
want to implement this spec.

Thanks,
Shaofei Cheng

2012/2/28 Brendan Eich 

> Indeed this has come up before:
>
> https://mail.mozilla.org/**pipermail/es5-discuss/2011-**
> January/003900.html
>
> No one replied then, alas.
>
> There's no normative significance, as Michael Dyck conjectured. It seems
> we could move Literal. Perhaps Waldemar or Allen has a preference. At this
> point I am ok with letting the traditional location of Literal stand.
>
> /be
>
> 程劭非 wrote:
>
>> Hi, everyone,
>>
>> I'm working a on ES parser recently and noticed something might be wrong
>> about the symbol “Literal”.
>>
>> Since “Literal” and “StringLiteral" "NumericLiteral" appears in lexical
>> grammar , I believe “Literal” should be a non-terminal symbol. Also there
>> is no other rule using “Literal” in lexical grammar. As all above I think
>> the following description is a syntactical grammar rule instead of a
>> lexical grammar rule:
>> /Literal /*::
>> ***/NullLiteral/
>>
>> /BooleanLiteral
>> NumericLiteral
>> StringLiteral/
>> /RegularExpressionLiteral/
>>
>>
>> So my suggest is moving the description from Annex A.1 to Annex A.3
>>
>>
>>
>> Thanks,
>> Shaofei Cheng
>> __**_
>> 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

Re: Should "Literal" in syntactical grammar instead of lexical grammar?

[Allen Wirfs-Brock]

Yes, Literal could be moved to the syntactic grammar. There is already some 
grammar refactoring like this going on in the Es6 draft.

The best way to capture these sorts of editorial issues is to file a bug using 
bugs.ecmascript.org against the current Es6 draft.

Allen




On Feb 28, 2012, at 2:50 AM, Brendan Eich wrote:

> Indeed this has come up before:
> 
> https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html
> 
> No one replied then, alas.
> 
> There's no normative significance, as Michael Dyck conjectured. It seems we 
> could move Literal. Perhaps Waldemar or Allen has a preference. At this point 
> I am ok with letting the traditional location of Literal stand.
> 
> /be
> 
> 程劭非 wrote:
>> Hi, everyone,
>> 
>> I'm working a on ES parser recently and noticed something might be wrong 
>> about the symbol “Literal”.
>> 
>> Since “Literal” and “StringLiteral" "NumericLiteral" appears in lexical 
>> grammar , I believe “Literal” should be a non-terminal symbol. Also there is 
>> no other rule using “Literal” in lexical grammar. As all above I think the 
>> following description is a syntactical grammar rule instead of a lexical 
>> grammar rule:
>> /Literal /*::
>> ***/NullLiteral/
>> 
>> /BooleanLiteral
>> NumericLiteral
>> StringLiteral/
>> /RegularExpressionLiteral/
>> 
>> So my suggest is moving the description from Annex A.1 to Annex A.3
>> 
>> 
>> 
>> Thanks,
>> Shaofei Cheng
>> ___
>> 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
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Allen Wirfs-Brock]

On Feb 28, 2012, at 3:07 AM, Brendan Eich wrote:

> Andreas Rossberg wrote:
>> On 28 February 2012 11:04, Brendan Eich  wrote:
>>> Fail-soft in JS1 was an artifact of lack of try-catch combined with too much
>>> rushed Unix philosophy. In cases such as delete you could get a status
>>> result (boolean telling whether the delete failed hard if false, else either
>>> succeeded or found no "own" property if true). In other cases of course an
>>> implicit coercion was done (*sigh*).
>>> 
>>> All water under the bridge but I agree we should not add more. Where do you
>>> see new fail-soft (or worse, fail-soft with ambiguity) being added?
>> 
>> Mainly destructuring, especially the implicit ToObject conversion of
>> the RHS that we have discussed a couple of months ago.
> 
> Oh right. Another implicit conversion, indeed. We could revisit this if you 
> feel strongly enough. It does not make me *sigh* though, because 
> destructuring signals intent to pluck properties off of objects, and as I 
> recall Allen suggested people will use this with a primitive RHS to get at 
> prototype methods.

There is also a matter of maintaining internal insistency within a language.  A 
language that consistently treats a common situation the say way everyplace it 
occurs is going to be easier to learn and feels more coherent than one that has 
contextually different behavior for the same situations. JS generally converts 
primitive values to wrapper objects whenever one is used in a context that 
requires an object.  If we start throwing exceptions in new feature contexts 
that require an object we are making the language less internally consistent. 
We should want to avoid that situation.  

Individual features shouldn't differ in common detail just because they were 
designed at different points in time or were defined by different people.  
These sorts of inconsistency are pretty easy to spot at the level of the code 
patterns used in the specification algorithms.  When I see deviations of this 
sort in proposal that I'm incorporating into the spec. I generally just fix 
them.

Specifically regarding ToObject.  It's use is important in minimizing the 
semantic differences between primitive values and Objects. In ES5 we eliminated 
the automatic wrapping of primitive values  used as this values in method 
invocations.  That means that in most cases 42 and (new Number(42)) can be used 
interchangeably. If we start leaving out ToObject calls in random places the 
distinction between a primitive value and a wrapped primitive values will start 
tripping people up.

Regarding the eval argument. It is actually the opposite situation.  If it was 
being consistent with most of the rest of the language it would have done a 
ToString to its argument. But it didn't and to make it consistent now seems  
like a risky breaking change. It's a good example of why it is important to be 
consistent form the start.  It's hard to correct later.

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New full Unicode for ES6 idea

[Brendan Eich]

Wes Garland wrote:
If four-byte escapes are statically rejected in BRS-on, we have a 
problem -- we should be able to use old code that runs in either mode 
unchanged when said code only uses characters in the BMP.


We've been over this and I conceded to Allen that "four-byte escapes" 
(I'll use \u to be clear from now on) must work as today with 
BRS-on. Otherwise we make it hard to impossible to migrate code that 
knows what it is doing with 16-bit code units that round-trip properly.


Accepting both 4 and 6 byte escapes is a problem, though -- what is 
"\u123456".length?  1 or 3?


This is not a problem. We want .length to distribute across 
concatenation, so 3 is the only answer and in particular ("\u1234" + 
"\u5678").length === 2 irrespective of BRS.


If we accept "\u1234" in BRS-on as a string with length 5 -- as we do 
today in ES5 with "\u123".length===4 -- we give developers a way to 
feature-test and conditionally execute code, allowing libraries to run 
with BRS-on and BRS-off.


Feature-testing should be done using a more explicit test. API TBD, but 
I don't think breaking "\u" with BRS on is a good idea.


I agree with you that Roozbeh is hardly used, so it can take the hit of 
having to feature-test the BRS. The much more common case today is JS 
code that blithely ignores non-BMP characters that make it into strings 
as pairs, treating them blindly as two "characters" (ugh; must purge 
that "c-word" abusage from the spec).


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Brendan Eich]

Andreas Rossberg wrote:

On 28 February 2012 11:04, Brendan Eich  wrote:

Fail-soft in JS1 was an artifact of lack of try-catch combined with too much
rushed Unix philosophy. In cases such as delete you could get a status
result (boolean telling whether the delete failed hard if false, else either
succeeded or found no "own" property if true). In other cases of course an
implicit coercion was done (*sigh*).

All water under the bridge but I agree we should not add more. Where do you
see new fail-soft (or worse, fail-soft with ambiguity) being added?


Mainly destructuring, especially the implicit ToObject conversion of
the RHS that we have discussed a couple of months ago.


Oh right. Another implicit conversion, indeed. We could revisit this if 
you feel strongly enough. It does not make me *sigh* though, because 
destructuring signals intent to pluck properties off of objects, and as 
I recall Allen suggested people will use this with a primitive RHS to 
get at prototype methods.


So I'm still in favor of the spec as proposed (and implemented in JS1.7+ 
in SpiderMonkey and Rhino -- no complaints or lost toes or fingers, to 
my knowledge).


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Second arguments for Array.prototype.sort: map function

[Brendan Eich]

Xavier MONTILLET wrote:

Here's an example:

var array = [ { v: 3.2 }, { v: 1.3 }, { v: 2.1 } ];
var compare = function ( a, b ) {
return a - b;
};
var transform = function ( x ) {
return { v: x.v - Math.floor( x.v ) };
};

var sortedArray = array.sort( compare, transform );

console.log( array.map( transform ) );// [ { v: .2 }, { v: .3 }, { v: 
.1 } ]
// you can see to sort it you need to take the last element and put it 
at the beginning

// so you do that on array:
console.log( sortedArray );// [ {  v: 2.1 }, {v: 3.2 }, {v: 1.3 } ]

So you sort the transformed array and you apply the exact same 
modifications to the original .


Is it clearer?



Yes, clear enough -- however adding new trailing arguments to an 
existing method is treacherous. It's likely calls in the wild pass a 
second argument by mistake. Less likely but still possible: an 
implementation has unwisely extended sort to have an optional second 
parameter already. This goes against the now-explicit NOTE in ES5:


NOTE Implementations that add additional capabilities to the set of 
built-in functions are encouraged to do so by adding new functions 
rather than adding new parameters to existing functions.


We could rule this out for the top five browser engines, but the 
possibility of extant code passing an extra actual parameter remains.


Better to have a new sortWithTransform method if necessary.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval on non-strings

[Andreas Rossberg]

On 28 February 2012 11:04, Brendan Eich  wrote:
> Fail-soft in JS1 was an artifact of lack of try-catch combined with too much
> rushed Unix philosophy. In cases such as delete you could get a status
> result (boolean telling whether the delete failed hard if false, else either
> succeeded or found no "own" property if true). In other cases of course an
> implicit coercion was done (*sigh*).
>
> All water under the bridge but I agree we should not add more. Where do you
> see new fail-soft (or worse, fail-soft with ambiguity) being added?

Mainly destructuring, especially the implicit ToObject conversion of
the RHS that we have discussed a couple of months ago.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "Literal" in syntactical grammar instead of lexical grammar?

[Brendan Eich]

Indeed this has come up before:

https://mail.mozilla.org/pipermail/es5-discuss/2011-January/003900.html

No one replied then, alas.

There's no normative significance, as Michael Dyck conjectured. It seems 
we could move Literal. Perhaps Waldemar or Allen has a preference. At 
this point I am ok with letting the traditional location of Literal stand.


/be

程劭非 wrote:

Hi, everyone,

I'm working a on ES parser recently and noticed something might be 
wrong about the symbol “Literal”.


Since “Literal” and “StringLiteral" "NumericLiteral" appears 
in lexical grammar , I believe “Literal” should be a non-terminal 
symbol. Also there is no other rule using “Literal” in lexical 
grammar. As all above I think the following description is 
a syntactical grammar rule instead of a lexical grammar rule:

/Literal /*::
***/NullLiteral/

/BooleanLiteral
NumericLiteral
StringLiteral/
/RegularExpressionLiteral/

So my suggest is moving the description from Annex A.1 to Annex A.3



Thanks,
Shaofei Cheng
___
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

Re: eval on non-strings

[Brendan Eich]

Andreas Rossberg wrote:

On 26 February 2012 19:32, Allen Wirfs-Brock  wrote:

The change can't be predicated on strict code because it concerns the 
definition of a built-in function that is called from any code. Strict mode 
restrictions must be tied to a lexical context.


We already distinguish direct eval, which is lexical, so we could make
a strict mode distinction there.

I agree it's hardly worth changing though. There are far more
hazardous places where the language opts for unhelpful "soft failure",
and it looks like we are even adding new ones.


Fail-soft in JS1 was an artifact of lack of try-catch combined with too 
much rushed Unix philosophy. In cases such as delete you could get a 
status result (boolean telling whether the delete failed hard if false, 
else either succeeded or found no "own" property if true). In other 
cases of course an implicit coercion was done (*sigh*).


All water under the bridge but I agree we should not add more. Where do 
you see new fail-soft (or worse, fail-soft with ambiguity) being added?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss