I’d be interested in other examples of implicit conversions stumping people.
What stumped who, when? Any bugs/github issues/blog posts to cite?
No, I think I agree with your assessment that implicit conversion to boolean
(the most prevalent implicit conversion) is manageable, possibly even
Le 31/12/2012 07:19, Boris Zbarsky a écrit :
On 12/30/12 1:20 PM, Claude Pache wrote:
FWIW, I used the fact that, in IE 8 9, innerHTML is conveniently a
configurable accessor found at Element.prototype (in IE8) or
HTMLElement.prototype (in IE9), for correcting a quirk of its setter,
by
2012/12/30 Allen Wirfs-Brock al...@wirfs-brock.com
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
* [[SetInheritance]]/Reflect.setPrototypeOf: I'm not sure this was
agreed upon. Especially since __proto__ is currently specified as a data
property. This means there is no setter that
2012/12/30 Allen Wirfs-Brock al...@wirfs-brock.com
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
* I'm a bit uncomfortable with the removal of property descriptor
normalization in the getOwnPropertyDescriptor/defineProperty traps.
Especially for getOwnPropertyDescriptor I think it's a
2012/12/31 Allen Wirfs-Brock al...@wirfs-brock.com
responses for chapter 8, except for 8.5 which will get its own message.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
Table 8:
* [[PreventExtensions]] internal method: should return a Boolean
success value
Why? no caller of
2012/12/31 Allen Wirfs-Brock al...@wirfs-brock.com
responses for chapter 8, except for 8.5 which will get its own message.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
8.4.4 Exotic Symbol Objects
Typo: A{n} Symbol object is an exotic object…
Exotic String objects have {the} a...
Hi David,
I generally support this view, although it may be too restrictive to
completely disallow non-standard exotics.
Instead, I would be happy if we could just state that non-standard exotics
are expected to uphold the invariants of the ES6 object model, which will
presumably be codified in
I'm surprised not to see Automatic Semicolon Insertion in the list.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Monday, December 31, 2012, Tom Van Cutsem wrote:
That said, I think this issue is orthogonal to our choice of whether or
not to expose setPrototypeOf as part of the MOP. Even if we do expose
it, any sandbox that wants to take away the ability the set the prototype
can simply poison
Le 31 déc. 2012 à 10:17, Axel Rauschmayer a...@rauschma.de a écrit :
I’d be interested in other examples of implicit conversions stumping people.
What stumped who, when? Any bugs/github issues/blog posts to cite?
No, I think I agree with your assessment that implicit conversion to boolean
On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote:
I'm surprised not to see Automatic Semicolon Insertion in the list.
Yes I would ditch ASI altogether if only to force the javascrhipsters to put
back each and every semicolon where it belongs: they are *delimiters*.
No ASI would force them
Personally, I have issues with from- and to-String conversions when working
with HTML form field values and data-* attributes. More precisely, I am
careful to make these conversions manually, and I regret that JS doesn't warn
me if I forget to do them. Indeed the following cases are
(b) ES6 sloppy mode cannot have let.
That's overstated, and as such it contradicts the tenuous consensus of the
last TC39 meeting: to reserve 'let' contextually in sloppy mode and
evangelize any let [x] = y code out there already (which we've yet to find
-- 'let' is used as an identifier,
Currently making a typo in property names can be fatal in two ways: When
reading a property, things fail silently and you get back `undefined`. When
setting a property, you accidentally create a new property.
A safer behavior would be as follows:
1. Creating properties
1a. Only property
Le 31 déc. 2012 à 18:58, Axel Rauschmayer a...@rauschma.de a écrit :
Personally, I have issues with from- and to-String conversions when working
with HTML form field values and data-* attributes. More precisely, I am
careful to make these conversions manually, and I regret that JS doesn't
On Sun, Dec 30, 2012 at 6:05 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
The primary issue is that most array-likes aren't array-like when it comes
to mutability. Most exposed indexed objects don't allow changes to their
indices, which is decidedly un-array-like for ~quarter of array
True, concat specifically needs to be changed. But it is the only Array
method that does that check (the only other internal checks
for brand BuiltinArray are in apply and isArray I think).
On Mon, Dec 31, 2012 at 1:33 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
On Sun, Dec 30, 2012 at
On 12/31/12 2:24 AM, David Bruant wrote:
Polyfillability is an interesting criteria. Is
Object.getOwnPropertyDescriptor polyfillability important? Would a good
[[Get]]+[[Set]] polyfill be enough? By that I mean that as long as the
[[Get]]+[[Set]] behavior is good, maybe polyfilling a property by
On Dec 31, 2012, at 10:39 AM, Brandon Benvie wrote:
True, concat specifically needs to be changed. But it is the only Array
method that does that check (the only other internal checks for brand
BuiltinArray are in apply and isArray I think).
In support of Array subclassing, I have a tweak
The work so far in the spec on enabling subclassing has been awesome and I
look forward to seeing this!
On Mon, Dec 31, 2012 at 1:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
In support of Array subclassing, I have a tweak to concat that allows
properly formed subclasses of Array to
I don't think ASI _per se_ is the problem. Rather, the restricted
productions bite people:
function foo() {
return
very + long + expression() + goes + here;
}
and of course, the expectation of ASI where there's no error to correct:
a = b
(function () {
... // lots of
Jorge Chamorro wrote:
On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote:
I'm surprised not to see Automatic Semicolon Insertion in the list.
Yes I would ditch ASI altogether if only to force the javascrhipsters to put
back each and every semicolon where it belongs: they are *delimiters*.
On Dec 31, 2012, at 7:28 AM, Brandon Benvie wrote:
On Monday, December 31, 2012, Tom Van Cutsem wrote:
That said, I think this issue is orthogonal to our choice of whether or not
to expose setPrototypeOf as part of the MOP. Even if we do expose it, any
sandbox that wants to take away the
Kevin Smith wrote:
(b) ES6 sloppy mode cannot have let.
That's overstated, and as such it contradicts the tenuous
consensus of the last TC39 meeting: to reserve 'let' contextually
in sloppy mode and evangelize any let [x] = y code out there
already (which we've yet to
On Dec 31, 2012, at 4:38 AM, Tom Van Cutsem wrote:
2012/12/31 Allen Wirfs-Brock al...@wirfs-brock.com
responses for chapter 8, except for 8.5 which will get its own message.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
8.4.4 Exotic Symbol Objects
Typo: A{n} Symbol object is an
The only motivation for me is in attempting to get rid of there even being
two modes. I don't really care if it was strict or not strict, just that
there's only one of them. Obviously the horse left the barn for ES5 long
ago, but the desire to collapse down to one mode in as much code as
possible
On Dec 31, 2012, at 10:14 AM, Axel Rauschmayer wrote:
Currently making a typo in property names can be fatal in two ways: When
reading a property, things fail silently and you get back `undefined`. When
setting a property, you accidentally create a new property.
A safer behavior would be
Allen Wirfs-Brock wrote:
On Dec 31, 2012, at 10:14 AM, Axel Rauschmayer wrote:
Currently making a typo in property names can be fatal in two ways: When
reading a property, things fail silently and you get back `undefined`. When
setting a property, you accidentally create a new property.
A
Brandon Benvie wrote:
The only motivation for me is in attempting to get rid of there even
being two modes. I don't really care if it was strict or not strict,
just that there's only one of them. Obviously the horse left the barn
for ES5 long ago, but the desire to collapse down to one mode in
I've just discovered that someone is fallen in the following pit:
Change of the semantic of function declarations in Firefox when included in
block (spoiler: hoisting issue).
(Not standard ES for sure, but definitely JS.)
Enjoy: http://statichtml.com/2011/spidermonkey-function-hoisting.html
Yes, see the thread starting at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027419.html
if you haven't.
The SpiderMonkey implementation was first, for what it's worth -- from
1997. ES3 did not specify any function in block production, of course.
The intersection with IE
And again, ES5 failed to reserve 'module' in strict mode, and ES1-3 never
reserved 'module', so ES6 must make 'module' only contextually reserved. We
are already in either it's an identifier, or it isn't default. If we can
do it for 'module', why not for 'let'?
Easy: module is still a first
Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in either it's an
identifier, or it isn't default. If we can do it for 'module',
why not for
Note: es-discuss is bcced, but please reply to public-script-coord.
The fact that instanceof for standard classes is completely broken
when multiple globals are involved has come up yet again, as Gecko
converts to WebIDL bindings.
The reason for that is that currently in Gecko's DOM bindings
The only place 'let' is contextually reserved in the quasi-consensus from
the last TC39 meeting is at the start of a statement, when followed by an
identifier, '{', or '['.
Right - which makes let a second class identifier (sorry,
made-up-term), since it can't be used in let[x] = y. I
shed
On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in either it's an
Kevin Smith wrote:
The only place 'let' is contextually reserved in the
quasi-consensus from the last TC39 meeting is at the start of a
statement, when followed by an identifier, '{', or '['.
Right - which makes let a second class identifier (sorry,
made-up-term), since it can't
Mark S. Miller wrote:
Thanks for clarifying the primacy of the rule. It was not clear, and it
does not match what Dave proposed that Mark reconfirmed as 1JS. Although
Dave left some wiggle room in his first post, I want to say that my attempts
to make all new body-forms strict don't fit
Domenic Denicola wrote:
What I realized is thattoday that is exactly the sort of code you wrap in an
IIFE, i.e. (function () { }());.
Script concatenation does not wrap an IIFE around the whole
concatenation, and cannot in general.
/be
___
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich
bren...@mozilla.comhttps://mail.google.com/mail/?view=cmfs=1tf=1to=bren...@mozilla.com
wrote:
Mark S. Miller wrote:
Thanks for clarifying the primacy of the rule. It was not clear, and it
does not match what Dave proposed that Mark reconfirmed
Mark Miller wrote:
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich bren...@mozilla.com
https://mail.google.com/mail/?view=cmfs=1tf=1to=bren...@mozilla.com
wrote:
Mark S. Miller wrote:
As I understood Dave's clarification, 1JS is orthogonal to our
decisions about how many
41 matches
Mail list logo
