On 29 December 2012 22:06, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
ES6+ will stay much longer (at least that's what we are working for).
Consequently, what should take precedence are the expectations and
needs of _future_ users of ES. Those who will come to ES6+ without
On 29 December 2012 22:11, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 29 December 2012 14:51, Axel Rauschmayera...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle
things?
Ideally? Backing out of the whole 1JS marketing
On 30 December 2012 02:31, Mark S. Miller erig...@google.com wrote:
If duplicate formals are the only such case, then I agree that the
fear of micro-mode is a non-issue. Do we have an accurate record of
the scoping of default value expressions? How about the interaction of
head scope and top
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use use strict; at top level enough, and
teaching them all will take time. Even then, because of the Law of Least
Effort, it'll be left out.
This is the major objection some of us keep raising,
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Sunday, December 30, 2012 00:06
by yoking ES6 feature adoption to strict mode adoption, you
multiply risks and reduce ES6 adoption.
I'd like to lend a
Andreas Rossberg wrote:
On 29 December 2012 22:06, Brendan Eichbren...@mozilla.com wrote:
Andreas Rossberg wrote:
ES6+ will stay much longer (at least that's what we are working for).
Consequently, what should take precedence are the expectations and
needs of _future_ users of ES. Those who
Andreas Rossberg wrote:
There
also is the sloppy-mode-arguments-object vs destructuring issue.
Thanks, I forgot that one. It's a good point, since one cannot
statically catch all 'arguments' uses in general.
Years ago we implemented destructuring parameters in JS1.7-1.8, without
I agree. To me it comes down to cognitive load. A good way of measuring that is
whether one can state a simple rule. For Andreas’ approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module around it.”
- Pro 1JS: You can use new stuff everywhere.
- Contra 1JS: You
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
On Dec 30, 2012, at 6:25 , Domenic Denicola dome...@domenicdenicola.com wrote:
Sadly
On 30 December 2012 11:58, Brendan Eich bren...@mozilla.com wrote:
Two separate things:
1. All new syntax with code bodies makes strict-by-fiat code bodies.
2. New parameter forms restrict duplicate parameters.
Neither entails various features locally chang[ing] the semantics of
unrelated
Axel Rauschmayer wrote:
It would actually be nice to have that as a feature: If the variable
name is `_` then it can be used multiple times. It’s a nice,
self-descriptive way of saying that you don’t care about a parameter value.
It is a valid identifier, one may actually use it. Better
On 30 December 2012 12:50, Axel Rauschmayer a...@rauschma.de wrote:
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore
It wouldn’t be breaking if it was the only identifier that one was allowed to
use multiple time, right?
But I do like the idea of the dot. Would be nice for destructuring arrays, too:
let [., ., third] = myArray;
On Dec 30, 2012, at 13:01 , Andreas Rossberg rossb...@google.com wrote:
On 30
On Sun, Dec 30, 2012 at 3:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
I agree. To me it comes down to cognitive load. A good way of measuring that
is whether one can state a simple rule. For Andreas’ approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module
On Sunday, December 30, 2012, Mark S. Miller wrote:
In the short term, while people are making the transition, the rule
would be stated as above “If you want the new stuff, turn on strict
mode or wrap a module around it.” Later, once ES6 is everywhere, it
would instead be stated as Turn on
On 12/29/12 10:49 PM, Boris Zbarsky wrote:
One other note.
And one last note, promise.
The point is that SpiderMonkey is working on changing its internal model
to more closely match the spec. And I agree with that approach: for any
somewhat complicated spec, using an internal model that
Le 30/12/2012 07:42, Boris Zbarsky a écrit :
On 12/29/12 11:08 AM, David Bruant wrote:
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
OK, but that's a problem methods
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as Ordinary object
semantics, when the functionality is absolutely of exotic functions. The
internal functions are no longer magical, as in completely outside the
bounds of
Le 30/12/2012 17:48, Boris Zbarsky a écrit :
On 12/29/12 10:49 PM, Boris Zbarsky wrote:
One other note.
And one last note, promise.
In my opinion, we get too rarely this kind of feedback from implementors
on es-discuss. I'm personally learning a lot.
The point is that SpiderMonkey is
Hi,
It's been suggested a couple times on the list that the hope for
non-standard exotic objects (ES6 terminology for ES5 host objects) is to
make them at most as powerful as proxies.
The current definition of exotic object says:
Exotic objects may implement internal methods in any manner
Axel Rauschmayer wrote:
I agree. To me it comes down to cognitive load. A good way of
measuring that is whether one can state a simple rule. For Andreas’
approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module
around it.”
That is different from what TC39 has
Hello,
thinking about class / new / super semantics and its problems, I came
with an idea. Big change on the first look, but in fact, imho, not so
big and making cleaner model.
tl;dr
Constructor function were workaround to specify constructor for a class
without `class`. Now, having
Brandon Benvie wrote:
On Sunday, December 30, 2012, Mark S. Miller wrote:
In the short term, while people are making the transition, the rule
would be stated as above “If you want the new stuff, turn on strict
mode or wrap a module around it.” Later, once ES6 is everywhere, it
- Pro 1JS: You can use new stuff everywhere.
- Contra 1JS: You can’t use all of the new stuff. There are tricky
exceptions and rules.
Check me: I think the only exceptions that we have found are let and
function-in-block. At the last TC39 meeting, we resolved to try reserving let
Axel Rauschmayer wrote:
I made a list of the 10 biggest JS pitfalls and most of them will be
gone under ES6. Much less to worry about, much easier to learn.
Could you share your 10-biggest list?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
I'll take that occasion to mention that I feel ES doesn't need class at all.
We've been using Object.create in a way that allow us to create objects as
prototypes for others, on these we add property descriptors, and then make
instances off these prototypes without adding anything.
We use a
Le 30 déc. 2012 à 19:20, David Bruant bruan...@gmail.com a écrit :
Interesting point.
Unrelated, but it's making me realize that innerHTML may stay a getter/setter
(not sure about inherited or not).
I guess the divide I'd like to put is between object state and what is
conveniently put as
[Starting a new thread, just in case.]
I made a list of the 10 biggest JS pitfalls and most of them will be gone
under ES6. Much less to worry about, much easier to learn.
Could you share your 10-biggest list?
1. Both undefined and null [not too much of a problem, easily learned]
2.
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Axel Rauschmayer
Sent: Sunday, December 30, 2012 16:22
9c) using methods as callback functions
The single biggest feature on my ES7 wishlist is the bind operator strawman:
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore wildcard is the exact syntax used in functional
languages, and very
My response to the general comments are below. I'll respond to comments for
specific sections in separate messages.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
Hi,
I did a thorough revision of Allen's Rev12 and Rev13 drafts which incorporate
(among many other things) the
On Sun, Dec 30, 2012 at 7:58 PM, David Bruant bruan...@gmail.com wrote:
To people who've been there for much longer than me, is it a shared feeling?
I think we're still quite bad at tests although it's getting better. I
agree with bz that if specifications diverge from the conceptual model
of
I'd say String.replace needs to be there:
http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html
http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design/
Also the fact that no built in html encode/decode exists.
(err, response not respinse...)
My response to the general comments are below. I'll respond to comments for
specific sections in separate messages.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
Hi,
I did a thorough revision of Allen's Rev12 and Rev13 drafts which incorporate
You did not include variants of
var i, a=[];
for (i=0; i 10; i++) {
a.push(print(i));
}
print(a[3]); /* output is 9 */
in your list. I see related bugs on a regular basis.
The other place I see regular bugs by intermediate coders is related to
'this' in events; but I'm not sure if we can
On Sun, Dec 30, 2012 at 10:22 PM, Axel Rauschmayer a...@rauschma.de wrote:
5. Array-like objects [not completely fixed (DOM...), but `arguments`
Specifics welcome, though probably better posted to www-...@w3.org.
We've made some effort towards changing some of this, but legacy
content is against
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Anne van Kesteren
Sent: Sunday, December 30, 2012 17:18
On Sun, Dec 30, 2012 at 10:22 PM, Axel Rauschmayer a...@rauschma.de wrote:
5. Array-like objects [not completely fixed (DOM...), but
I think that nothing wins over dot or underscore for marking unused
positions, for one simple reason: it is implemented for years in every engines
in constructs like:
var myArray = [ , , third]
So it seems more natural to me to have something like: function( , , z) { /*
... */ }
But anyway,
Axel Rauschmayer wrote:
1. Both undefined and null [not too much of a problem, easily learned]
2. Truthy and falsy values [not pretty, but I’ve grown used to them
and the convenient but sloppy “has a value” checks via `if`]
These are usually winning. Dart makes you be explicit in testing and
On Sun, Dec 30, 2012 at 11:23 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I saw this happen, and was sad, but never understood what the legacy problem
was.
https://bugs.webkit.org/show_bug.cgi?id=81573
In particular https://bugs.webkit.org/show_bug.cgi?id=81573#c45
The problem
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Anne van Kesteren
Sent: Sunday, December 30, 2012 17:18
On Sun, Dec 30, 2012 at 10:22 PM, Axel Rauschmayera...@rauschma.de wrote:
5. Array-like objects [not completely fixed
You did not include variants of
var i, a=[];
for (i=0; i 10; i++) {
a.push(print(i));
}
print(a[3]); /* output is 9 */
in your list. I see related bugs on a regular basis.
That would be (7). The above should work. The problem only exists with
functions (or rather, closures):
The problem was code that incorrectly assumed instanceof to mean that the
instance was an Array in combination with Array.prototype.concat.
There was a bug in Google's Closure Library which caused almost all
Google's apps to fail due to this. The library was updated as soon as this
was found but
Yes, tripped me up a few times. Then I remember to use a regular expression
with a /g flag as the first argument. I wouldn’t consider it a major pitfall,
but it is definitely a pitfall.
On Dec 30, 2012, at 23:06 , gaz Heyes gazhe...@gmail.com wrote:
I'd say String.replace needs to be there:
To clarify, my message was about making NodeLists have Array.prototype in
its prototype chain.
On Dec 30, 2012 5:50 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
The problem was code that incorrectly assumed instanceof to mean that the
instance was an Array in combination with
Axel Rauschmayer wrote:
You did not include variants of
var i, a=[];
for (i=0; i 10; i++) {
a.push(print(i));
}
print(a[3]); /* output is 9 */
in your list. I see related bugs on a regular basis.
That would be (7). The above should work. The problem only exists with
functions (or
Wouldn't it be possible to make a copy of the provided descriptor object
and otherwise work the same as it is currently specified? This retains the
ability to set and get custom descriptor attributes without making the
stored record mutable, which seems like the primary concern.
On Sun, Dec 30,
- Implicit conversions are messy (and a superset of pitfall #2), but seem to
surprise people much less than the above items.
I think you have it backwards.
My experience, so far. I’d be interested in other examples of implicit
conversions stumping people.
- Modules close another
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 operations.
It would be useful for there to be a separate Indexed class/prototype
that
Another thought: What will JavaScript code look like once 99% of browsers in
use support ES6? Will we have a language with coherent semantics and a
simple structure? That is: is there a way to drop some of the trickiness,
long term? And which of the approaches gets us there?
In the short term,
On Dec 30, 2012, at 2:57 PM, Brandon Benvie wrote:
Wouldn't it be possible to make a copy of the provided descriptor object and
otherwise work the same as it is currently specified? This retains the
ability to set and get custom descriptor attributes without making the stored
record
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:
...
=== Chapter 8 ===
8.1.6.2
Unless explicitly specified otherwise, internal data properties may be
dynamically added to ECMAScript objects.
Isn't it safer to err
Ah yes, I take it back. For some reason I had the mistaken notion that the
[[Origin]] was somehow planned to propagate/persist further, rather than
just being a way to support lossless maybe-forward (I believe this is the
purpose?). I must have crossed signals on something else, since I recall
You don't mean for-of, you mean for (let i...) in any form. We want all
for-let forms to make fresh let bindings per iteration. That's what your
resolution for (7) should say, and ES6 does indeed aim to do this.
Yes, thanks. I thought only for-of did this.
We can work around it by changing
Claus Reinke wrote:
// suggestion
Perhaps there is a way to make the automated upgrade
problem solvable/cheap? Instead of ES6+ supporting sloppy
mode and strict mode and mixtures of new features with
sloppy mode indefinetly, how about turning the situation
on its head:
- ES6 engines default to
Axel Rauschmayer wrote:
- Implicit conversions are messy (and a superset of pitfall #2), but
seem to surprise people much less than the above items.
I think you have it backwards.
My experience, so far. I’d be interested in other examples of implicit
conversions stumping people.
What
Axel Rauschmayer wrote:
JS is functional first, not OOP first. APIs that want methods to be
extractable as bound to the object from which they were extracted
must do extra work, which can be self-hosted via getters for specific
methods, or a general proxy.
Again, not sure if that’s feasible,
This is a bit long - bear with me...
First, let me make one more argument as to why new syntax, just use it
won't work:
(a) In ES6, let is the preferred way to declare variables. Let's not be
relativistic to the point of goo here. Block-scoped variables are
better. As such, let is of central
On 12/30/12 10:31 AM, Brandon Benvie wrote:
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as Ordinary object
semantics, when the functionality is absolutely of exotic functions.
Can you please define exotic functions?
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 extracting it and replacing it
with a corrected
On 12/30/12 10:20 AM, David Bruant wrote:
I would say that the difference lies in the fact that properties which
usually materialize the object state clearly are a per-instance thing
while object methods usually are stateless functions
The line is fuzzy (as usual). Is the innerHTML getter
On 12/30/12 10:58 AM, David Bruant wrote:
I'm not enough familiar with CSSOM getters and CSS transitions, sorry;
is it a spec requirement or an observation shared for all current
implementations?
The spec requirement is that transitions start when computed values change.
The spec does not
Kevin Smith wrote:
This is a bit long - bear with me...
First, let me make one more argument as to why new syntax, just use
it won't work:
(a) In ES6, let is the preferred way to declare variables. Let's
not be relativistic to the point of goo here. Block-scoped variables
are better. As
Boris Zbarsky wrote:
On 12/30/12 10:31 AM, Brandon Benvie wrote:
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as Ordinary object
semantics, when the functionality is absolutely of exotic functions.
Can you please
On 12/30/12 10:53 PM, Brendan Eich wrote:
Think ES1-5 host objects.
Yeah, anything that needs that sort of thing is already not described as
accessors in WebIDL. Accessors are for the cases which can be
implemented entirely with normal objects plus perhaps WeakMap to store
the
65 matches
Mail list logo
