Re: Object copy
Thanks for your answers. Object.assign seems good but provides only copy for enumerable properties, not a real deep clone. I know for jquery, that's why i precised only for DOM but it was just to show the syntax :) 2014-06-11 0:00 GMT+02:00 Rick Waldron waldron.r...@gmail.com: On Tue, Jun 10, 2014 at 12:32 PM, Maxime Warnier mar...@gmail.com wrote: Hi All Do you know if it is planned or maybe in discussion for ES7 to have a simple clone system on objects ? There are different notations, from : - jquery Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] ) jQuery doesn't clone objects, it clones DOM elements. Rick -- Maxime ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object copy
Hi Maxime, Good to see you here :-) This topic has been discussed recently on Twitter. See https://twitter.com/jeremyckahn/status/474259042005553154 I'm like Rick's answer in particular https://twitter.com/rwaldron/status/475017360085364736 as I believe a large share of cloning is just about data As discussed in this Twitter thread, immutable data structures would be an interesting idea too. If an object is guaranteed to be deeply immutable, then, it can be passed around without the need for cloning. Clones are only necessary because the initial object is mutable in the first place. Immutable data structures have been briefly discussed here recently: https://mail.mozilla.org/pipermail/es-discuss/2014-June/037429.html (see replies too) David Le 11/06/2014 08:49, Maxime Warnier a écrit : Thanks for your answers. Object.assign seems good but provides only copy for enumerable properties, not a real deep clone. I know for jquery, that's why i precised only for DOM but it was just to show the syntax :) 2014-06-11 0:00 GMT+02:00 Rick Waldron waldron.r...@gmail.com: On Tue, Jun 10, 2014 at 12:32 PM, Maxime Warnier mar...@gmail.com wrote: Hi All Do you know if it is planned or maybe in discussion for ES7 to have a simple clone system on objects ? There are different notations, from : - jquery Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] ) jQuery doesn't clone objects, it clones DOM elements. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object copy
Hi David :) thanks for the links ! You are right, it's generally about data. Serialize an object to JSON prevent from sharing references. On the twitter feed Jeremy talks about optimizing the process . I'm agree with that, for performance and a nicer syntax. By the way, the Object.deepFreeze is really interesting , especially for an API and when you want to set some private properties . But I think it is a workaround to the issue of cloning because you can't freeze all objects and maybe you want to have a mutable object but cloning it afterward. 2014-06-11 9:58 GMT+02:00 David Bruant bruan...@gmail.com: Hi Maxime, Good to see you here :-) This topic has been discussed recently on Twitter. See https://twitter.com/jeremyckahn/status/474259042005553154 I'm like Rick's answer in particular https://twitter.com/rwaldron/status/475017360085364736 as I believe a large share of cloning is just about data As discussed in this Twitter thread, immutable data structures would be an interesting idea too. If an object is guaranteed to be deeply immutable, then, it can be passed around without the need for cloning. Clones are only necessary because the initial object is mutable in the first place. Immutable data structures have been briefly discussed here recently: https://mail.mozilla.org/pipermail/es-discuss/2014-June/037429.html (see replies too) David Le 11/06/2014 08:49, Maxime Warnier a écrit : Thanks for your answers. Object.assign seems good but provides only copy for enumerable properties, not a real deep clone. I know for jquery, that's why i precised only for DOM but it was just to show the syntax :) 2014-06-11 0:00 GMT+02:00 Rick Waldron waldron.r...@gmail.com: On Tue, Jun 10, 2014 at 12:32 PM, Maxime Warnier mar...@gmail.com wrote: Hi All Do you know if it is planned or maybe in discussion for ES7 to have a simple clone system on objects ? There are different notations, from : - jquery Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] ) jQuery doesn't clone objects, it clones DOM elements. Rick -- Maxime WARNIER ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object copy
On Wednesday, June 11, 2014, Maxime Warnier mar...@gmail.com wrote: Thanks for your answers. Object.assign seems good but provides only copy for enumerable properties, not a real deep clone. I know for jquery, that's why i precised only for DOM but it was just to show the syntax :) Oops, sorry, I overlooked that. Rick 2014-06-11 0:00 GMT+02:00 Rick Waldron waldron.r...@gmail.com javascript:;: On Tue, Jun 10, 2014 at 12:32 PM, Maxime Warnier mar...@gmail.com javascript:; wrote: Hi All Do you know if it is planned or maybe in discussion for ES7 to have a simple clone system on objects ? There are different notations, from : - jquery Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] ) jQuery doesn't clone objects, it clones DOM elements. Rick -- Maxime ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
IsConstructor
A variety of places in the spec use the new IsConstructor abstract operation. In ES5, this test (essentially, does the object implement the [[Construct]] internal method) was restricted to the `new` operator. But in ES6, it is used in implementing a large variety of built-in functions: - All Array methods - All %TypedArray% methods - All Promise methods (via NewPromiseCapability) (Note that there are two uses: arrays and typed arrays do alternative logic for non-constructors; promises fail immediately. This inconsistency might be a bug?) It seems to me that we should expose this primitive reflective operation to users, instead of having all of these methods be able to detect something that user code can't, and thus making them harder to explain or polyfill. Alternately, if we don't think users should be doing this kind of reflection, then we probably shouldn't be doing it ourselves. In which case, figuring out an alternate path for the above methods would be useful---perhaps they simply try to construct, and fail immediately if used with a non-constructible object, instead of falling back. WDYT? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Rationale for dropping ModuleImport syntax?
I really just want single exports and destructuring of single exports...?? I would second that. I have seen no desire for any static analysis beyond this module depends on that module and I've seen no desire for live bound imports. I accept that we're messing with a fragile consensus, but the removal of ModuleImport syntax has already done that, so we're way beyond purely cosmetic changes. I think if this is done wrong it will just do more harm than good, and further fragment the ecosystem. We need something that makes the upgrade path for CommonJS users really simple and clear. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
IsConstructor
Another way of thinking of IsConstructor is whether the function has an own prototype property or not. The only exception[*] there is bound functions where one would need to know if the [[TargetFunction]] IsConstructor or not. [*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. On Wed Jun 11 2014 at 10:24:49 AM, Domenic Denicola dome...@domenicdenicola.com wrote: A variety of places in the spec use the new IsConstructor abstract operation. In ES5, this test (essentially, does the object implement the [[Construct]] internal method) was restricted to the `new` operator. But in ES6, it is used in implementing a large variety of built-in functions: - All Array methods - All %TypedArray% methods - All Promise methods (via NewPromiseCapability) (Note that there are two uses: arrays and typed arrays do alternative logic for non-constructors; promises fail immediately. This inconsistency might be a bug?) It seems to me that we should expose this primitive reflective operation to users, instead of having all of these methods be able to detect something that user code can't, and thus making them harder to explain or polyfill. Alternately, if we don't think users should be doing this kind of reflection, then we probably shouldn't be doing it ourselves. In which case, figuring out an alternate path for the above methods would be useful---perhaps they simply try to construct, and fail immediately if used with a non-constructible object, instead of falling back. WDYT? ___ 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: IsConstructor
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. [[Construct]] is only attached to a proxy if the target has a [[Construct]] internal method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]] internal method) was restricted to the `new` operator. But
in ES6, it is used in implementing a large variety of built-in functions:
- All Array methods
- All %TypedArray% methods
- All Promise methods (via NewPromiseCapability)
(Note that there are two uses: arrays and typed arrays do alternative
logic for non-constructors; promises fail immediately. This inconsistency
might be a bug?)
It seems to me that we should expose this primitive reflective operation
to users, instead of having all of these methods be able to detect
something that user code can't, and thus making them harder to explain or
polyfill.
Alternately, if we don't think users should be doing this kind of
reflection, then we probably shouldn't be doing it ourselves. In which
case, figuring out an alternate path for the above methods would be
useful---perhaps they simply try to construct, and fail immediately if used
with a non-constructible object, instead of falling back.
I had similar questions a couple years ago and Allen advised that the
easiest polyfill for such a mechanism is:
function isConstructor(C) {
try {
new C();
return true;
} catch (e) {
return false;
}
}
Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an
ES7 standard library module that exported the abstract operations that
are now defined in chapter 7
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-abstract-operations,
the response was positive but it was far too early to have a serious
discussion. Anyway, with that you'd just write:
import { isConstructor } from es-abstract;
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]] internal method) was restricted to the `new` operator. But
in ES6, it is used in implementing a large variety of built-in functions:
- All Array methods
- All %TypedArray% methods
- All Promise methods (via NewPromiseCapability)
(Note that there are two uses: arrays and typed arrays do alternative
logic for non-constructors; promises fail immediately. This inconsistency
might be a bug?)
It seems to me that we should expose this primitive reflective operation
to users, instead of having all of these methods be able to detect
something that user code can't, and thus making them harder to explain or
polyfill.
Alternately, if we don't think users should be doing this kind of
reflection, then we probably shouldn't be doing it ourselves. In which
case, figuring out an alternate path for the above methods would be
useful---perhaps they simply try to construct, and fail immediately if used
with a non-constructible object, instead of falling back.
I had similar questions a couple years ago and Allen advised that the
easiest polyfill for such a mechanism is:
function isConstructor(C) {
try {
new C();
return true;
} catch (e) {
return false;
}
}
Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an
ES7 standard library module that exported the abstract operations that
are now defined in chapter 7
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-abstract-operations,
the response was positive but it was far too early to have a serious
discussion. Anyway, with that you'd just write:
import { isConstructor } from es-abstract;
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
This, as well as the other warning I posted.
Rick
For example, this will fail if C === window.Worker in a browser.
-Boris
___
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
deleting strict references: SyntaxError or syntax error?
According to paragraph 11.4.1 of ECMA262 v.5.1, and in particular to
point 5.a of that paragraph, a catchable SyntaxError exception should
be thrown when deleting a strict reference in strict mode. The code
below tests this feature:
var fun = function (){
use strict; // strict mode
delete x; // strict reference
};// this assignment should execute fine
try {
fun (); // this should throw a SyntaxError
}
catch (e){
alert(exception caught as expected);
}
We found that current browsers instead terminate abruptly the script
execution at parse time, with an error message. This behaviour is
typical of early errors, described in Chapter 16, but it is not
obvious that the one above should be considered an early error.
Ch.16 says that syntax errors must be reported early. Now, while the
code foo( ^*bar((] is clearly a syntax error, it's not obvious that
throwing a SyntaxError exception should also be considered a syntax
error in the same sense. (Section 11.1.5 states explicitly a case where
the latter should happen, but 11.4.1 does not.)
so, should every occurrence in the spec of the wording throw a
SyntaxError exception be taken to have the implicit subscript unless
this can be reported as an early error, or are the browsers diverging
from the spec?
the jscert.org team
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just
need to wait until Proxies are available everywhere! ;-)
On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron waldron.rick at gmail.com
https://mail.mozilla.org/listinfo/es-discuss
wrote:
/
//
//
// On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
// domenic at domenicdenicola.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
//
// A variety of places in the spec use the new IsConstructor abstract
// operation. In ES5, this test (essentially, does the object implement the
// [[Construct]] internal method) was restricted to the `new` operator. But
// in ES6, it is used in implementing a large variety of built-in functions:
//
// - All Array methods
// - All %TypedArray% methods
// - All Promise methods (via NewPromiseCapability)
//
// (Note that there are two uses: arrays and typed arrays do alternative
// logic for non-constructors; promises fail immediately. This inconsistency
// might be a bug?)
//
// It seems to me that we should expose this primitive reflective operation
// to users, instead of having all of these methods be able to detect
// something that user code can't, and thus making them harder to explain or
// polyfill.
//
//
// Alternately, if we don't think users should be doing this kind of
// reflection, then we probably shouldn't be doing it ourselves. In which
// case, figuring out an alternate path for the above methods would be
// useful---perhaps they simply try to construct, and fail immediately if
used
// with a non-constructible object, instead of falling back.
//
//
// I had similar questions a couple years ago and Allen advised that the
// easiest polyfill for such a mechanism is:
//
// function isConstructor(C) {
//try {
// new C();
// return true;
//} catch (e) {
// return false;
//}
// }
//
//
// Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an
// ES7 standard library module that exported the abstract operations that
// are now defined in chapter 7
// http://people.mozilla.org/~jorendorff/es6-draft.html#sec-abstract-operations,
http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-abstract-operations,
// the response was positive but it was far too early to have a serious
// discussion. Anyway, with that you'd just write:
//
// import { isConstructor } from es-abstract;
//
//
// Rick
//
/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: deleting strict references: SyntaxError or syntax error?
On 6/11/14, 11:08 AM, Sergio Maffeis wrote: According to paragraph 11.4.1 of ECMA262 v.5.1, and in particular to point 5.a of that paragraph, a catchable SyntaxError exception should be thrown when deleting a strict reference in strict mode. ... We found that current browsers instead terminate abruptly the script execution at parse time, with an error message. This behaviour is typical of early errors, described in Chapter 16, but it is not obvious that the one above should be considered an early error. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-static-semantics-early-errors says that delete foo where foo is an identifier is an early error in strict mode, as far as I can tell. so, should every occurrence in the spec of the wording throw a SyntaxError exception be taken to have the implicit subscript unless this can be reported as an early error, or are the browsers diverging from the spec? Browsers are implementing ES6, not ES5.1. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com: [*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. No, only proxies whose target has a [[Construct]] method will themselves have a [[Construct]] method. IOW, proxies should be completely transparent w.r.t. the IsConstructor test. See 9.5.15 ProxyCreate step 5.b. I believe there may be a spec bug, as step 4 should explicitly exclude [[Construct]] and [[Call]], yet seems to include all methods defined in sec 9.5. Allen? Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in a browser.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in a browser.
It will also fail for the uses of `IsConstructor` in the promise spec,
as `Promise` constructors throw `TypeError` unless they are passed a
callable `resolve` argument (IIRC).
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote: Quick note: that isConstructor isn't really viable unless you plan on using it with constructors that do not have side effects. Rick The Proxy-based solution needs to be used in these cases. Now we just need to wait until Proxies are available everywhere! ;-) Not sure Proxy solve anything when we want to test the constructor nature of a function and be sure invoking it won't change anything in the current application context To highlight what side-effects mentioned by Rick could be, a tested function while invoked may: - do DOM Manipulations, - change properties in the global object, - initiate Web Sockets or Web Workers... Not safe at all... Testing the prototype is also one thing, but constructors can have no prototype properties or methods but only own properties defined at the instance level (potentially with getters / setters) As created dynamically, such own properties are hard if not impossible to detect without executing the constructor The only safe way I would see, for functions written in JS, would be to use a lexer on the source of the function provided by Function.prototype.toString.call(C) But it would still not be 100% perfect and should probably throw an exception or return a error in some situations in which this manipulation may not be detectable. ex: the function code evaluate a dynamic strings (that can not be parsed by a lexer) via eval(), setTimeout()/ setInterval(), or new Function() Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 6/11/2014 5:40 PM, Alexandre Morgaut wrote:
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just need to
wait until Proxies are available everywhere! ;-)
Not sure Proxy solve anything when we want to test the constructor nature of a
function and be sure invoking it won't change anything in the current
application context
To highlight what side-effects mentioned by Rick could be, a tested function
while invoked may:
- do DOM Manipulations,
- change properties in the global object,
- initiate Web Sockets or Web Workers...
Not safe at all...
From [1]:
```javascript
function IsConstructor(o) {
try {
new (new Proxy(o, {construct: () = ({})}));
return true;
} catch(e) {
return false;
}
}
```
This IsConstructor implementation does not trigger any side-effects and
works even when the underlying constructor requires arguments etc.
[1]
https://github.com/anba/es6draft/blob/master/src/test/scripts/suite/lib/assert.js#L53-L60
[...]
Alexandre Morgaut
Wakanda Community Manager
4D SAS
60, rue d'Alsace
92110 Clichy
France
Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web : www.4D.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 11, 2014, at 8:16 AM, Tom Van Cutsem wrote: 2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com: [*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. No, only proxies whose target has a [[Construct]] method will themselves have a [[Construct]] method. IOW, proxies should be completely transparent w.r.t. the IsConstructor test. See 9.5.15 ProxyCreate step 5.b. I believe there may be a spec bug, as step 4 should explicitly exclude [[Construct]] and [[Call]], yet seems to include all methods defined in sec 9.5. Allen? Kind of boarder line. 6.1.7.2 says that the essential internal methods are those listed in Table 5 (does not include [[Call]] and [[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in 9.5 each include a note that says these internal methods are only provided when a corresponding internal method exists on the target. Reading the section as a while, I think it is pretty clear that that a Proxy only has a [[Construct]] internal method if its target also has one. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 11, 2014, at 8:49 AM, André Bargull wrote:
From [1]:
```javascript
function IsConstructor(o) {
try {
new (new Proxy(o, {construct: () = ({})}));
return true;
} catch(e) {
return false;
}
}
```
This IsConstructor implementation does not trigger any side-effects and works
even when the underlying constructor requires arguments etc.
[1]
https://github.com/anba/es6draft/blob/master/src/test/scripts/suite/lib/assert.js#L53-L60
+1.
I was just about to write and post the equivalent.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
4 June 2014 TC39 Meeting Notes
# June 4 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip
Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth
Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK),
Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich
(BE), Mark Miller (MM), Peter Jensen (PJ)
## Adoption of the agenda
https://github.com/tc39/agendas/blob/master/2014/06.md
AWB: Adding section 8: Other ES6 Technical Issues
AWB: Adding Report from ECMA secretariat to HTML integration section
SK: Add an agenda item to discuss JSDoc and its use in editors
AWB: add ArrayBuffer neutering to ES6 agenda items
## Conclusion/Resolution
- Agenda Approved
- Minutes from April 2014 approved
## Scheduling of TC39 meeting
JN: Meeting schedule changes are problematic
- In november, we'll select for next year.
- The current meeting dates need to be approved now and committed to
YK: Didn't weigh scheduling concerns of champions vs. non-champions well
AWB: Hard to weigh those concerns until we know what will be talked about
Next:
- 29-31 July 2014 at Microsoft in Redmond, WA (USA)
- 23-25 September 2014 at Bocoup in Boston, MA (USA)
- 18-20 November 2014 at PayPal in San Jose, CA (USA)
(posted: http://www.ecma-international.org/memento/TC39-M.htm )
AWB: Should set agendas based on schedule, rather than other way around
JN: I will propose meeting dates in September for your consideration
## Agenda for this meeting
DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich
and potentially Andy Wingo
## 4.2 Schedule Review
AWB: Goal was to present ES6 to ECMA general assembly for approval later
this year, meaning we need to approve finished draft at September meeting,
meaning we need a finished draft at July meeting. I don't see any way we
can have even an approximately finished draft by July. Also starting to get
good implementer feedback which is causing spec churn, but there are pieces
missing review. If we ratified what we have now we'd be missing serious
implementation feedback.
AWB: Propose we slip our publication target by 6 months. Spec will still be
feature frozen. We're just fixing bugs and accepting implementer feedback.
Concern 1: is this opening the door to feature creep? Important it doesn't
do that.
Concern 2: Will this simply delay implementer work by 6 months?
Concern 3: Perception of committee failure?
DH: We should move forward on the work and message that we're doing so.
Spec is not what drives the work, spec is the final capture of a stable
consensus. I'm OK with the spec slipping.
WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping
buggy spec, and later abandoning it.
?: Hazy distinction between calling something a bug vs. a revisited
conclusion.
WH: The issues with E4X were clearly bugs.
AWB: This committee can tell the difference between fixing bugs and
revisiting conclusions.
AWB: Focus energy on ES7 [if you want to revisit conclusions]!
AWB: Other factor playing into spec review is test262, to which we've just
gotten approval to accept contributions
JN: Can we approve the change of dates (presenting finished draft to TC39
committee in November rather than July)?
AWB: Everything we want to include is in the spec at some level of quality,
it's just a matter of ensuring quality.
YK: If you're an implementer, you shouldn't treat this as a slippage.
AWB: Should we start naming spec editions using years rather than an
incrementing number (ES2015 vs. ES6)?
AWB: Let's not throw this in with messaging about the schedule postponement.
YK: The fact that people are used to ES5/ES6/etc. will make the change
important as a messaging technique.
BE: Let's sleep on it.
## Conclusion/Resolution
- Postponement of presentation of final ES6 draft agreed upon
- Switch to yearly naming convention to be slept on
## Update on changes to spec since last meeting
AWB: See Draft Rev 25 section of
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
AWB: Object.prototype.toString.call(proxy) will be either [object Object]
or [object Function] depending on whether the proxy is callable, so that
there is no way to tell that an object is a Proxy
MM: Have to choose between use cases, and being able to hide Proxy-ness is
the better choice
AWB: Already considered/dropped isProxy, so using O.p.toString as a
back-door would have been inconsistent with that decision
AWB: Another Proxy issue MM and I talked about: custom property descriptor
attributes on Proxies, specifically adding additional attributes to the
descriptor that the Proxy could recognize.
```js
Object.defineProperty(obj, propName, {
value: whatever,
customAttribute: attrValue
});
// Should the
5 June 2014 TC39 Meeting Notes
# June 5 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip
Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth
Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK),
Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich
(BE), Mark Miller (MM), Peter Jensen (PJ)
**quiet typing**
(Agenda item 5.2 added)
(Istvan on the phone discussing non-member CLA process)
AR: It sounds like we're making the process difficult for non-members
simply because it's currently difficult for members. Can we change the goal
to just make the process simpler for everyone?
IS: We just need the process to be the same for members and non-members.
That is the current process -- we need the pdf form
AR: Can you take it back to the assembly(?) as a request from this TC that
we'd like to simplify the process for signing the CLA to a click-through
form for everyone [members and non-members]
IS: Yes, I can do that
**discussion**
## Conclusion/Resolution
- Allen will continue to work with Istvan on this
- Not clear how to proceed concretely other than having members continue to
push for this
- Current process includes printing pdf, signing it, scanning it
## JSDoc*, JSIDL*, Code Editors
(Ask for slides)
SK: Type inferencing is hard
SK: JSDoc*, we need help from the user.
SK: Standardize JSDoc?
SK: JSDoc Proposal
AR: We are the only group that can add syntax so we should not put
semantics in the comments.
AR: Interested in designing a type system
DH: I'm skeptic that we can design a type system for ES.
DH: Describes kinds of type systems: sound, unsound, guards
WH: I tried it for ES4. Came to the conclusion that a complex static type
system would not work for ES's plethora of array-like things. On the other
hand, more primitive type systems for things such as strings, numbers,
classes are eminently doable and useful.
WH: I had a proposal for guards. These are more like a max min solution.
DH: Guards are too dynamic.
WH: In order for a type system to be useful, it must be enforceable in some
form in order to catch erroneous or out-of-date type annotations.
DH: It is about as much a green field as defining a new language. It can
mean so many different things.
JM: Would like to explore types for documentation at least.
DH: If there is no standard there will continue to be a proliferation of
tools.
WH: We know this is a large space to explore. That does not mean that we
should not explore it.
YK: If we make this a priority it will take years and years of discussion,
dropping everything else.
BT: We can manage doing more than one thing at the same time.
AWB: This discussion feels like the early discussions of class syntax. Yet
we were able to make progress.
DH: TypeScript is the strongest proposal at this point. Guards have serious
problems for structural types. A sound type system (for JS) is still an
academic research topic without a solution in sight.
YK: TS type system is incompatible with ES6.
YK: TS is a fork of ES5.
WH: These problems of incompatible forking are exactly why we need to take
over this work.
f
AR: I want this for ES7
AWB: We haven't yet started to prioritize our next work items.
DH: The cost is very very high and IMO there are more important thing to
work on than types.
WH: IMO documentable types are one of the highest priorities for us now.
There is a lot of external interest as evidenced by the various external
efforts.
BN: Strict scrutiny (e.g. from DH) can and should come before the proposal
comes before TC39.
SK: Back to slides... Not proposing a type system. Implementors are
interested in standardizing JSDoc..
SK: JS IDL?
SK: Type definition...
## Conclusion/Resolution
- Stage 0 to work on JSDoc
## Closing Iterators
(Dave presenting, send slides!)
Slides: https://speakerdeck.com/dherman/closing-iterators
Notes that key stakeholders have signed off on this (Andy Wingo, Luke
Hoban, ... others)
**DH talking about breaking out of loops and calling .return() when an
abrupt exit occurs in the loop**
WH: Does a yield inside a for loop call the return method in the normal
case?
BN: No.
WH: What if that yield then gets killed by a break in the caller?
BN: Show example.
WH:
```javascript
function * a() {
for (let x of y) {
...
yield ...
...
}
}
for (let b of a()) {
break;
}
```
** Discussing: How should abrupts inside a yield* get bubbled? **
BN: Any yield on which the generator (or any nested delegate generators)
are currently suspended effectively become returns, so the return value
bubbles all the way out to become the result of the outermost generator.
WH: (back to his code example) What does a's return method do?
MM: The break in the for
6 June 2014 TC39 Meeting Notes
# June 6 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip
Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth
Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK),
Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich
(BE), Mark Miller (MM)
## Follow up on deferring comprehensions
DH: IMHO Andy Wingo's email made my case stronger since it added another
dimension that we need to take into account.
AWB: Let's leave it in until next meeting and try to resolve this before
then.
DH: This is basically a go/no go question.
AWB: No spec changes will be done until after we have consensus.
DH: There is no rush to get it out of the spec.
## Conclusion/Resolution
- Resolve this online
- Make a go/no go at the next face to face meeting.
## Block scoping issues
BT: In sloppy mode
```js
foo(); // maybe?
if (test) function foo() {};
foo(); // yes
```
AWB: Wanted to hold the line and not cover this.
BT: One option is to treat the FunctionDeclaration in if as if there was a
Block around it.
AWB: The changes in the grammar to support this would be nasty.
WH: Don't want to pollute strict or non-browser-compatibility mode with
this stuff.
AWB: This won't affect strict mode.
WH: Then it shouldn't be in the main grammar. Leave it in Annex B.
BT: Can we hand wave this in Annex B? Can we just use prose to say that it
behavase as if there was a block around it?
BE: Without grammar we cannot validate
WH: I'm not going to validate the grammar in Annex B. I already know
there's ugliness there.
## Conclusion/Resolution
- Substatement function declarations will be added to Annex B unless we can
convince ourselves it's safe to remove.
- Allen will investigate how to specify in Annex B (including whethe we
need to specify the grammar or hand-wave).
## Initializer in for-in
AWB: Got feedback that there are 11 sites that use the code pattern.
WAB: https://bugzilla.mozilla.org/show_bug.cgi?id=748550
## Conclusion/Resolution
- Have an engine try to remove support and report back. Otherwise it will
have to be added back to the spec.
## Rest properties and spread properties (Sebastian Markbåge)
Presentation notes: https://gist.github.com/sebmarkbage/aa849c7973cb4452c547
SM: Rest properties
```js
let {x, y, ...z} = {x: 1, y: 2, a: 3, b: 4};
x; // 1
y; // 2
z; // {a: 2, b: 4}
```
SM: Spread properties
```js
let n = {x, y, ...z};
n; // {x: 1, y: 2, a: 3, b: 4}
```
SM: The [[Prototype]] will be %ObjectPrototype%
MM: It should not use the original prototype since it does not have the
same properties
WH: What about about non enumerable own properties
SM: Only enumerable are copied.
WH: What about accessors?
SM: Either snapshot the value or copy the accessor.
WH: How do accessors behave in existing destructuring?
AWB: They snapshot the value.
WH: So that's how accessors should behave here too.
SM: Precedence set by `Object.assign`. So that means that we would use a
`Get` to get the value.
WH: Does destructuring look into prototypes? Concrete example:
let {x, y, ...z} = {y: 2, a: 3, b: 4} where the RHS object inherits
from a prototype whose x property is 7. What is the value assigned to the x
variable?
SM: Yes, it'd assign 7 to x.
WH: Then it would be bizarre for x to snapshot properties from the
prototype but for z to ignore them
MM: Can you do let {x, y, ...something-more-complex-than-an-identifier}?
SM: No.
MM: Properties must be added via defineProperty, not put.
AWB, BE: Yes, that's how object literals work. Don't want to accidentally
run setters in the prototype.
MM: This extends possibilities for dynamic name clash errors in strict mode.
[Discussion about whether dynamic or static name clashes in object literals
should be errors or rightmost-one-wins.]
WH: Whatever we do, let's be consistent. Don't want one rule for explicitly
named properties, another confusing rule for dynamically generated
properties.
WH: If the spread only uses own properties than it is inconsistent with
destructuring.
YK, DH: No, the problem is to figure out the key names for ... and after
that we do a Get
MM: Are methods enumerable? (Yes) Then I think this is fatal
DH: We have to look at existing code and all existing code uses
for-in+hasOwnProperty
WH: I want substitutability, so that I can pick of properties one by one.
BE:
```js
z = Object.create({w: 42});
obj = {x, y, ...z};
```
WH: Wants w to show up in obj.
JM, BN: If you want to pick up objects from the proto you can use
`__proto__`, as in { x, y, ...z.__proto__, ...z }. The other way does not
hold (if we include non own by default).
MM: Very confortable with Yehuda's rational that we use own properties to
find the property
Re: 4 June 2014 TC39 Meeting Notes
Expanded Conclusion/Resolution for the ArrayBuffer neutering discussion: ## Conclusion/Resolution - Don't add isNeutered yet, and expect clients use try-catch when accessing properties to determine status. - Also remember to change the name. Released? Vacated? - Any attempt to access (read or write) binary data elements of an ArrayBuffer that has been neutered will throw a TypeError exception. - Accessing the byteLength property of an ArrayBuffer that has been neutered will throw TypeError exception. - Have not yet decided what happens to the the length, byteOffset, and byteLength properties of a TypedArray whose underlying ArrayBuffer gets neutered. - Keep the behavior that out of bounds reads of a TypedArray (whose buffer has not been neutered) returns undefined (MM: or throws, in strict mode) and that out of bounds write are no-ops (MM: throws in strict mode). TC39 recognizes that the above are breaking changes relative to the Khronos spec. but we believe that the behavior of silently treating neutered buffers as 0-length buffers is seriously flawed and would set a terrible precedent for any future transferable data types. Ben His errors are volitional and are the portals of discovery. -- James Joyce On Wed, Jun 11, 2014 at 9:08 AM, Ben Newman benja...@cs.stanford.edu wrote: # June 4 2014 Meeting Notes Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben Newman (BN), Filip Pizlo (FP), Sebastian Markbage (SM), Rafael Weinstein (RWS), Jaswanth Sreeram (JS), Alex Russell (AR), Istvan Sebestyen (IS), Simon Kaegi (SK), Arnoud Le Hors (ALH), Reid Burke (RB), Erik Arvidsson (EA), Brendan Eich (BE), Mark Miller (MM), Peter Jensen (PJ) ## Adoption of the agenda https://github.com/tc39/agendas/blob/master/2014/06.md AWB: Adding section 8: Other ES6 Technical Issues AWB: Adding Report from ECMA secretariat to HTML integration section SK: Add an agenda item to discuss JSDoc and its use in editors AWB: add ArrayBuffer neutering to ES6 agenda items ## Conclusion/Resolution - Agenda Approved - Minutes from April 2014 approved ## Scheduling of TC39 meeting JN: Meeting schedule changes are problematic - In november, we'll select for next year. - The current meeting dates need to be approved now and committed to YK: Didn't weigh scheduling concerns of champions vs. non-champions well AWB: Hard to weigh those concerns until we know what will be talked about Next: - 29-31 July 2014 at Microsoft in Redmond, WA (USA) - 23-25 September 2014 at Bocoup in Boston, MA (USA) - 18-20 November 2014 at PayPal in San Jose, CA (USA) (posted: http://www.ecma-international.org/memento/TC39-M.htm ) AWB: Should set agendas based on schedule, rather than other way around JN: I will propose meeting dates in September for your consideration ## Agenda for this meeting DH: Talk about generators tomorrow (Thursday), to accommodate Brendan Eich and potentially Andy Wingo ## 4.2 Schedule Review AWB: Goal was to present ES6 to ECMA general assembly for approval later this year, meaning we need to approve finished draft at September meeting, meaning we need a finished draft at July meeting. I don't see any way we can have even an approximately finished draft by July. Also starting to get good implementer feedback which is causing spec churn, but there are pieces missing review. If we ratified what we have now we'd be missing serious implementation feedback. AWB: Propose we slip our publication target by 6 months. Spec will still be feature frozen. We're just fixing bugs and accepting implementer feedback. Concern 1: is this opening the door to feature creep? Important it doesn't do that. Concern 2: Will this simply delay implementer work by 6 months? Concern 3: Perception of committee failure? DH: We should move forward on the work and message that we're doing so. Spec is not what drives the work, spec is the final capture of a stable consensus. I'm OK with the spec slipping. WH: Don't want to repeat E4X (ECMAScript-for-XML) experience of shipping buggy spec, and later abandoning it. ?: Hazy distinction between calling something a bug vs. a revisited conclusion. WH: The issues with E4X were clearly bugs. AWB: This committee can tell the difference between fixing bugs and revisiting conclusions. AWB: Focus energy on ES7 [if you want to revisit conclusions]! AWB: Other factor playing into spec review is test262, to which we've just gotten approval to accept contributions JN: Can we approve the change of dates (presenting finished draft to TC39 committee in November rather than July)? AWB: Everything we want to include is in the spec at some level of quality, it's just a matter of ensuring quality. YK: If you're an implementer,
Re: IsConstructor
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote: A variety of places in the spec use the new IsConstructor abstract operation. In ES5, this test (essentially, does the object implement the [[Construct]] internal method) was restricted to the `new` operator. But in ES6, it is used in implementing a large variety of built-in functions: - All Array methods - All %TypedArray% methods - All Promise methods (via NewPromiseCapability) (Note that there are two uses: arrays and typed arrays do alternative logic for non-constructors; promises fail immediately. This inconsistency might be a bug?) Maybe you're looking at things differently from me, but I only see use of IsConstructor in a few Array methods, not all of them. For most places in the spec. if you trace the logic of the algorithms that use IsConstructor it be being used as a guard on a [[Construct]] call and the alternative path is to throw a TypeError. In ES code this would be done automatically by the 'new' operator but must be done explicitly in the pseudo-code. A JS self-hosted implementation of those algorithm that used 'new' would not need to do an explicit IsConstructor test in most of those cases. There are a few uses of IsConstructor in some Array methods that deal with subtle backwards compat issues that are a result of extending Array to be subclassable. These are very unique cases and I don't think you should look at them as establishing a pattern that should be followed in other situations. Array.from and Array.of have a non-throwing IsConstrutor test because they are designed to allow things like this: let of = Array.of; of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5) I don't recall why we provided that functionality. It doesn't seem to me like a pattern we should want to encourage. It seems to me that we should expose this primitive reflective operation to users, instead of having all of these methods be able to detect something that user code can't, and thus making them harder to explain or polyfill. Most of these uses are simply emulating the behavior of the 'new' operator so it really shouldn't be needed to be tested explicitly in a polyfill. When it is really need, a user land IsConstructor test can be written using Proxy. Alternately, if we don't think users should be doing this kind of reflection, then we probably shouldn't be doing it ourselves. In which case, figuring out an alternate path for the above methods would be useful---perhaps they simply try to construct, and fail immediately if used with a non-constructible object, instead of falling back. WDYT? Other than the Array.of and Array.from usages the other uses are all necessary either functionally (you can't just try to construct by calling [[Construct]], it requires an explicit guard) or to deal with special backwards compat situations. I'd be happy to eliminate the special handling in Array.of and Array.from if there is consensus that it isn't desirable. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Array.from and Array.of have a non-throwing IsConstrutor test because they are designed to allow things like this: let of = Array.of; of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5) I don't recall why we provided that functionality. It doesn't seem to me like a pattern we should want to encourage. Why not just require: ```javascript let of = Array.of.bind(Array); of(1,2,3,4,5); ``` That seems like it would work just as well, and not require special handling in the spec. I'd be happy to eliminate the special handling in Array.of and Array.from if there is consensus that it isn't desirable. I don't need it. (Although `es6-shim` currently seems to implement the special handling correctly.) --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 11 June 2014 18:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Other than the Array.of and Array.from usages the other uses are all necessary either functionally (you can't just try to construct by calling [[Construct]], it requires an explicit guard) or to deal with special backwards compat situations. I'd be happy to eliminate the special handling in Array.of and Array.from if there is consensus that it isn't desirable. I'd be in support of that. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote: A variety of places in the spec use the new IsConstructor abstract operation. In ES5, this test (essentially, does the object implement the [[Construct]] internal method) was restricted to the `new` operator. But in ES6, it is used in implementing a large variety of built-in functions: - All Array methods - All %TypedArray% methods - All Promise methods (via NewPromiseCapability) (Note that there are two uses: arrays and typed arrays do alternative logic for non-constructors; promises fail immediately. This inconsistency might be a bug?) Maybe you're looking at things differently from me, but I only see use of IsConstructor in a few Array methods, not all of them. For most places in the spec. if you trace the logic of the algorithms that use IsConstructor it be being used as a guard on a [[Construct]] call and the alternative path is to throw a TypeError. In ES code this would be done automatically by the 'new' operator but must be done explicitly in the pseudo-code. A JS self-hosted implementation of those algorithm that used 'new' would not need to do an explicit IsConstructor test in most of those cases. There are a few uses of IsConstructor in some Array methods that deal with subtle backwards compat issues that are a result of extending Array to be subclassable. These are very unique cases and I don't think you should look at them as establishing a pattern that should be followed in other situations. Array.from and Array.of have a non-throwing IsConstrutor test because they are designed to allow things like this: let of = Array.of; of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5) I don't recall why we provided that functionality. It doesn't seem to me like a pattern we should want to encourage. It seems to me that we should expose this primitive reflective operation to users, instead of having all of these methods be able to detect something that user code can't, and thus making them harder to explain or polyfill. Most of these uses are simply emulating the behavior of the 'new' operator so it really shouldn't be needed to be tested explicitly in a polyfill. When it is really need, a user land IsConstructor test can be written using Proxy. Alternately, if we don't think users should be doing this kind of reflection, then we probably shouldn't be doing it ourselves. In which case, figuring out an alternate path for the above methods would be useful---perhaps they simply try to construct, and fail immediately if used with a non-constructible object, instead of falling back. WDYT? Other than the Array.of and Array.from usages the other uses are all necessary either functionally (you can't just try to construct by calling [[Construct]], it requires an explicit guard) or to deal with special backwards compat situations. I'd be happy to eliminate the special handling in Array.of and Array.from if there is consensus that it isn't desirable. I don't see the incentive in removing the special handling from these two cases when there is obvious end-programmer benefit: minifiers can safely alias Array.of and Array.from without needing to use .bind(Array) when declaring that alias. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
Saving 12 bytes does not seem like an obvious end-programmer benefit to me. It seems like unnecessary and premature optimization. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: IsConstructor
It's also deceptive: it makes you think `Array.of` and `Array.from` are functions, when in reality they are definitely methods. From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian ecmascr...@cscott.net Sent: Wednesday, June 11, 2014 13:31 To: Rick Waldron Cc: EcmaScript Subject: Re: IsConstructor Saving 12 bytes does not seem like an obvious end-programmer benefit to me. It seems like unnecessary and premature optimization. --scott ___ 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: IsConstructor
2014-06-11 18:02 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Kind of boarder line. 6.1.7.2 says that the essential internal methods are those listed in Table 5 (does not include [[Call]] and [[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in 9.5 each include a note that says these internal methods are only provided when a corresponding internal method exists on the target. Reading the section as a while, I think it is pretty clear that that a Proxy only has a [[Construct]] internal method if its target also has one. Ok, the fact that an explicit note is included in 9.5.13 [[Call]] and 9.5.14 [[Construct]] should be sufficient to avoid any doubt. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The initialization steps for Web browsers
On Jun 10, 2014, at 9:35 PM, Ian Hickson wrote: On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote: No, that's not the intent of the ES design. The EnqueueTask abstract operations takes the name of a specific Job queue as an argument and always places the newly created PendingJob record into the named queue. It's important because the enqueuing order for a specific queue determine the relative ordering of the Jobs in that queue. The whole reason we have a separate queue for promise Jobs is because we need to preserve that execution ordering. Microtasks also preserve execution ordering. My point is just that we need to maintain more than just promise callback ordering -- we need to maintain the relative order of promise callbacks and all the other things that trigger microtasks. In the ES spec. I can only deal with things that are known to ES. I need to be able to specify relative ordering of promise Jobs. And I (implicitly) say that the ordering of promise jobs relative to script evaluation jobs is unspecified. I need to be able to expressed at least those concepts, without referring to specific host concepts, such as microtasks. As far as I can tell, ScriptTasks (or ScriptJobs) isn't actually used anywhere in the spec except in 8.5 Initialization to queue a job. In particular, nothing in NextTask is sensitive to the precise names of the queues, it just grabs tasks from any job queue. Yes, ScriptJobs essentially provides the default mechanism for a host to feed script execution requests to the ES engine. But, a host really doesn't have to use it. A ScriptEvaluationJob can be placed in any queue and dispatched by NextJob. In practice, since we have to coordinate all the other tasks going on, and since script execution for legacy scripts is not queued up in a job queue but is instead done synchronously from HTML tasks, it seems like the simplest way to actually manage this from the HTML side is to just spoon feed the ES algorithms a single job at a time, so than NextTask only ever has one job to chose from. But you would still need to respect ordering relationships ES imposes, such as those for promise Jobs. You could in your NextJob extensions remove all entries from the PromiseJobs queue and (while preserving relative ordering) move them into your own scheduler. Then feed them back to ES individually when you've decided that it's time to dispatch them. This also seems like it would be easiest to implement from browsers, since it means they'd only need one task management system (the HTML event loop), and their requirements with respect to NextTask would boil down to just run this task, with no need to manage any queues at all. That seems fine, as long as you preserve the ES specified Job orderings. The way I think about it is that HTML schedule queue needs to feed down to ES Job queues because it is the ES Jobs that define the actual execution semantics of ES code. Well, we need to feed down to the specific algorithms that set up the execution contxts and realms and so on, sure. But that's separate from the job queues per se, no? Right, that's essentially what the initial and final non-scheduleing related steps of NextJob takes care of. HTML could schedule a microtask into the PromiseJobs queue if the microtask needs to be executed after all pending promise Jobs. Or you could define you own ES MicrotaskJobs queue and define the ES scheduling relationship between it and the ES ScriptJobs and PromiseJobs queues. We already have an event loop mechanism, I don't think it makes sense to just recast the whole HTML mechanism into a JS mechanism. (JavaScript is optional in browsers, after all -- we wouldn't want a browser to simply not start up if the user disabled JS!) We have Object.observe coming for ES and there is significant interest in having event-loop constructs as part of the core ES host independent environment. Just like for promises, the ES spec. will have to define their semantics and any scheduling requirements for any associated Jobs in a manner that is independent of HTML or any other host environment. Ideally, we probably should be designing this stuff in the context of several different host environments. You're the HTML integration point, and I try to keep a command-line JS host in mind. Ideally somebody from a a more complex host such as Node should also be playing along. Finally, note that anything that is internally defined to use promises (for example, module loading phases) will end up getting schedule through the PromiseJobs queue as part of the promise resolution processing. Yeah. I'm still wrapping my head around exactly how to integrate the module loading stuff with all the other loading and dependency management that HTML does. Personally, I'd try to keep it all as local as possible. There are many kinds of resources with
Re: IsConstructor
I may still try to tighten up the language. I usually consider even one person being uncertain about the meaning of some prose in the spec. to be an indication that others will probably also be confused. Allen On Jun 11, 2014, at 10:49 AM, Tom Van Cutsem wrote: 2014-06-11 18:02 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Kind of boarder line. 6.1.7.2 says that the essential internal methods are those listed in Table 5 (does not include [[Call]] and [[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in 9.5 each include a note that says these internal methods are only provided when a corresponding internal method exists on the target. Reading the section as a while, I think it is pretty clear that that a Proxy only has a [[Construct]] internal method if its target also has one. Ok, the fact that an explicit note is included in 9.5.13 [[Call]] and 9.5.14 [[Construct]] should be sufficient to avoid any doubt. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: IsConstructor
From: Allen Wirfs-Brock al...@wirfs-brock.com There are a few uses of IsConstructor in some Array methods that deal with subtle backwards compat issues that are a result of extending Array to be subclassable. These are very unique cases and I don't think you should look at them as establishing a pattern that should be followed in other situations. Can you expand on these a bit more? What would happen if they threw when used on non-constructors? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 11, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
There are a few uses of IsConstructor in some Array methods that deal with
subtle backwards compat issues that are a result of extending Array to be
subclassable. These are very unique cases and I don't think you should look
at them as establishing a pattern that should be followed in other
situations.
Can you expand on these a bit more? What would happen if they threw when used
on non-constructors?
Here is some ES5 code that would fail if the IsConstructor test in map threw
for a non-constructor:
var o = [];
o.constructor = undefined;
o.map(function(){}) instanceof Array
/*
true
*/
We're already walking a compatibility tight-rope to make sure that:
class SubA extends Array {};
( new SubA).map(x=x) instanceof SubA //true in ES6, would have been false in
ES5
It's hard to say where we need to maintain strict backwards compatibility and
where we can diverge to support new functionality but an over-riding ES6
guideline has been to bend backwards to minimize breaking changes.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
Yes, you're right.
What about Array subclasses? `from` and `of` are inherited when Array is
subclassed, so these:
22.1.2.3 4 5 (
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of)
22.1.2.1 8.a 8.b (
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from)
22.1.2.1 13 14
Which are are how `from` and `of` determine what to construct, will be
replaced with a single step, being one of:
Let A be the result of calling the [[Construct]] internal method of C with
an empty argument list.
Let A be the result of calling the [[Construct]] internal method of C with
an argument list containing the single item len.
But surely this step will also have to be guarded by IsCallable(this),
which that means this:
If IsConstructor(C) is true, then
Let A be the result of calling the [[Construct]] internal method of C
with an empty argument list.
Else,
Let A be ArrayCreate(0).
Becomes:
If IsCallable(C) is true, then
Let A be the result of calling the [[Construct]] internal method of C
with an empty argument list.
Else,
Let A be ArrayCreate(0).
Or maybe that's not necessary? Is it preferable to just throw when someone
writes any of these:
let of = Array.of;
of(1,2,3,4);
let from = Array.from;
from(arrayLikeOrIterable);
let List = {
of: Array.of
};
List.of(1, 2, 3, 4);
(Note that `Array.isArray` doesn't cease to work correctly when aliased)
With the IsConstructor or IsCallable guard, these just work; without any
guard, they'll throw TypeError exceptions: object is not a function or
undefined is not a function (in strict mode). Neither of these errors are
very obvious. Of course this can all be fixed with .bind() or a bind
operator, but it just seems unfortunate to throw out something that's not
harming the spec in favor something that might be problematic in end user
code.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: IsConstructor
From: Rick Waldron waldron.r...@gmail.com Or maybe that's not necessary? Is it preferable to just throw when someone writes any of these: I think it is indeed preferable, as would happen when using any other method (`this`-dependent function) without a `this`. (Note that `Array.isArray` doesn't cease to work correctly when aliased) `Array.isArray` is not a method, but a function; it does not change behavior depending on its `this` value. With the IsConstructor or IsCallable guard, these just work; without any guard, they'll throw TypeError exceptions: object is not a function or undefined is not a function (in strict mode). Neither of these errors are very obvious. I disagree that this is not obvious. This is the same error you always get when aliasing a method and trying to use it as a function. Of course this can all be fixed with .bind() or a bind operator, but it just seems unfortunate to throw out something that's not harming the spec in favor something that might be problematic in end user code. This is a bit of a slippery-slope argument; the end result is that every method should have a default `this` value that it's soft-bound to, in order to coddle the users who might get confused. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
I would second that. I have seen no desire for any static analysis beyond this module depends on that module and I've seen no desire for live bound imports. I believe that viewpoint is adequately represented in the status quo. No need to legislate other viewpoints away. I accept that we're messing with a fragile consensus, but the removal of ModuleImport syntax has already done that, so we're way beyond purely cosmetic changes. Well, you're assuming exactly the state of affairs that this thread is questioning... The fact that the threat of changing things to this degree has dredged up such polarized opinions should indicate that we ought to be leaving things alone. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Of course this can all be fixed with .bind() or a bind operator, but it
just seems unfortunate to throw out something that's not harming the spec in
favor something that might be problematic in end user code.
This is a bit of a slippery-slope argument; the end result is that every
method should have a default `this` value that it's soft-bound to, in order
to coddle the users who might get confused.
And from my perspective, trying to fix the users' bugs for them is a
very dangerous slope indeed. You are producing behavior that doesn't
match the user's mental model of how `this` *should* work (ie, how it
works for all other methods). Some developer is going to get badly
confused when a falsy or unusual `this` doesn't throw a `TypeError` as
they expect (allowing them to identify and debug the problem) but
instead silently succeeds returning an object of an arbitrary class.
I was walking a newish JS developer through a similar issue last
night, when they wanted to know why the standard JS inheritance
doesn't work for `Error`:
```javascript
var MyError = function(msg) { Error.call(this, msg); };
MyError.prototype = new Error();
MyError.prototype.constructor = MyError;
console.log((new MyError(foo)).message); // prints... undefined ?!
```
Why doesn't `message` get initialized? Surprise, it's because in ES5
invoking `Error` as a function ignores the given `this` and
substitutes a new one, which is a brand-new instance of `Error`, and
returns *that*. This made my developer friend cry. (This is hacked
around in ES6 so that `class MyError extends Error` is sane.)
We shouldn't make this mistake in ES6. Use the `this` which the
author of the code provided and don't second-guess them, or else they
will tear at their hair in confusion.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith zenpars...@gmail.com wrote: Well, you're assuming exactly the state of affairs that this thread is questioning... The fact that the threat of changing things to this degree has dredged up such polarized opinions should indicate that we ought to be leaving things alone. ...or that the compromise is making nobody happy, in which case perhaps we've be better off with a simpler design which at least *some* people really liked? I don't know. My personal opinion is that the modules stuff still feels like the odd duck which is being shoved into ES6 even though it's not quite ready yet. But I'm hoping it all works out in the end... --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote: On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola dome...@domenicdenicola.com wrote: It's also deceptive: it makes you think `Array.of` and `Array.from` are functions, when in reality they are definitely methods. Yes, you're right. What about Array subclasses? `from` and `of` are inherited when Array is subclassed, so these: 22.1.2.3 4 5 (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of) 22.1.2.1 8.a 8.b (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from) 22.1.2.1 13 14 Which are are how `from` and `of` determine what to construct, will be replaced with a single step, being one of: Let A be the result of calling the [[Construct]] internal method of C with an empty argument list. Let A be the result of calling the [[Construct]] internal method of C with an argument list containing the single item len. But surely this step will also have to be guarded by IsCallable(this), which that means this: If IsConstructor(C) is true, then Let A be the result of calling the [[Construct]] internal method of C with an empty argument list. Else, Let A be ArrayCreate(0). Becomes: If IsCallable(C) is true, then that's not an adequate guard, be an object can be callable but not have a [[Construct]] internal method so the next step not be valid Let A be the result of calling the [[Construct]] internal method of C with an empty argument list. Else, Let A be ArrayCreate(0). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron waldron.r...@gmail.com Or maybe that's not necessary? Is it preferable to just throw when someone writes any of these: I think it is indeed preferable, as would happen when using any other method (`this`-dependent function) without a `this`. (Note that `Array.isArray` doesn't cease to work correctly when aliased) `Array.isArray` is not a method, but a function; it does not change behavior depending on its `this` value. I wasn't arguing that it was or wasn't, but I guess my point wasn't clear, so that's my mistake: most web developers won't know or care about the difference. With the IsConstructor or IsCallable guard, these just work; without any guard, they'll throw TypeError exceptions: object is not a function or undefined is not a function (in strict mode). Neither of these errors are very obvious. I disagree that this is not obvious. This is the same error you always get when aliasing a method and trying to use it as a function. Of course this can all be fixed with .bind() or a bind operator, but it just seems unfortunate to throw out something that's not harming the spec in favor something that might be problematic in end user code. This is a bit of a slippery-slope argument; the end result is that every method should have a default `this` value that it's soft-bound to, in order to coddle the users who might get confused. Fair enough, I give up, it's all yours to behead. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On Wed, Jun 11, 2014 at 4:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote: On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola dome...@domenicdenicola.com wrote: It's also deceptive: it makes you think `Array.of` and `Array.from` are functions, when in reality they are definitely methods. Yes, you're right. What about Array subclasses? `from` and `of` are inherited when Array is subclassed, so these: 22.1.2.3 4 5 ( http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of) 22.1.2.1 8.a 8.b ( http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from) 22.1.2.1 13 14 Which are are how `from` and `of` determine what to construct, will be replaced with a single step, being one of: Let A be the result of calling the [[Construct]] internal method of C with an empty argument list. Let A be the result of calling the [[Construct]] internal method of C with an argument list containing the single item len. But surely this step will also have to be guarded by IsCallable(this), which that means this: If IsConstructor(C) is true, then Let A be the result of calling the [[Construct]] internal method of C with an empty argument list. Else, Let A be ArrayCreate(0). Becomes: If IsCallable(C) is true, then that's not an adequate guard, be an object can be callable but not have a [[Construct]] internal method so the next step not be valid I wasn't recommending this, I was illustrating that removing IsConstructor benefits no one and hurts the overall programming experience. This one only one layer of the illustration. Either way, I've given up on presenting reasons why the IsConstructor guard was useful. It's too bad that no one who wanted those aliasing options bothered to speak up. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
I have been working extensively with modules in a project that will be
going live this year. I am using traceur and I find myself often doing the
following:
module fs from fs;
var { readFile } = fs;
OR
import { readFile as _readFile } from fs;
var
readFile = _readFile;
It's partially due to the way module's get transpiled, if I were to just
do `import { readFile } from fs` then every reference to readFile in the
source ends up looking like `deps[0][readFile]()`
Transpile aside, I don't want that performance concern. Most of the time I
want a real solid reference and the only way to get it as the spec stands
is to import something and then cache it locally. Isn't that kind of crazy?
- Matthew Robb
On Wed, Jun 11, 2014 at 12:54 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith zenpars...@gmail.com wrote:
Well, you're assuming exactly the state of affairs that this thread is
questioning... The fact that the threat of changing things to this
degree
has dredged up such polarized opinions should indicate that we ought to
be
leaving things alone.
...or that the compromise is making nobody happy, in which case
perhaps we've be better off with a simpler design which at least
*some* people really liked?
I don't know. My personal opinion is that the modules stuff still
feels like the odd duck which is being shoved into ES6 even though
it's not quite ready yet. But I'm hoping it all works out in the
end...
--scott
___
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
Module import syntax (leading / trailing from)
Hi,
It's probably too late to raise an objection, but anyway.
I've tried to find out the rational for the import [...] from [...]
syntax (rather than the common from [...] import [...]), and only found
the following old thread :
http://esdiscuss.org/topic/simpler-sweeter-syntax-for-modules, especially
this sentence :
I came to this because earlier versions of the syntax were inconsistent
about whether from meant the-module-itself or an-export-of-the-module,
which made it even more confusing. This new syntax was inspired by Python,
but with import as the leading keyword, rather than from. Which is what
leads to the inversion of order.
However, I'm still not quite sure to understand why is the import key
leading here. It sounds definitely better when speaking (since it's correct
valid english), but I don't find it very nice when wrote in a source code.
For example, I've got a lot of source code in multiple languages where the
imports are sorted according to their categories (vendors / app) and name,
ie something like :
define( [
'vendors/Backbone,
'vendors/Underscore',
'vendors/JQuery',
'models/Note',
'models/Users',
'views/Note',
'views/User',
'settings'
], [...] )
Using the ES6 syntax, however, comes to :
import { Backbone } from 'vendors/Backbone';
import { _ }from 'vendors/Underscore';
import { $ }from 'vendors/JQuery';
import { NoteModel : Note, UserModel : User } from 'models';
import { NoteView : Note, UserView : View } from 'views';
import { MAX_NOTES } from 'settings';
The pythonic syntax (leading from) would have been
from 'vendors/Backbone' import { Backbone };
from 'vendors/Underscore' import { _ };
from 'vendors/JQuery' import { $ };
from 'models' import { NoteModel : Note, UserModel : User };
from 'views'import { NoteView : Note, UserView : User };
from 'settings' import { MAX_NOTES };
Which, I think, is clearer : the reader knows what are the components used
by the module at the first glance. A trailing from sounds more difficult
to read, since it may be at the right of the screen (or even hidden
depending on the screen width).
I would also argue that knowing the module is more important than knowing
the symbols, since multiple modules can export the same symbols, and then
the reader has to parse the destructuring import to know what is the symbol
purpose (or look at the right).
Finally, symbols are often added / removed in a source code. However, a
module name doesn't often change. Using a trailing from may be a burden
for OCD-driven developers who like to keep some kind of indentation inside
their code.
import { NoteModel : Note, UserModel : User } from 'models';
import { MAX_NOTES } from 'settings';
Which becomes after a new feature
import { NoteModel : Note, UserModel : User, ReferenceModel : Reference
} from 'models';
import { MAX_NOTES }
from 'settings';
Then again after a refactoring
import { BookModel : Book, UserModel : User } from 'models';
import { MAX_NOTES } from 'settings';
The issue also arises in some extreme cases (this example comes from
Traceur) :
import { ARGUMENT_LIST, ARRAY_LITERAL_EXPRESSION, BINARY_OPERATOR,
BINDING_IDENTIFIER, CALL_EXPRESSION, [...], PAREN_EXPRESSION,
PROPERTY_NAME_ASSIGNMENT, REST_PARAMETER, SYNTAX_ERROR_TREE } from
'./trees/ParseTreeType';
In such a case, it's not very clear which is the module holding those
symbols (our eyes are trained to read from the top to the bottom, and I
think there's also a pythonic legacy which attracts the eyes at the top to
find the module name).
That's a purely cosmethic note, and I'm very satisfied by the current
direction of ES6; I was just wondering if this point had been discussed
before.
Thanks,
--
Maël Nison (arcanis https://twitter.com/arcanis)
Frontend Developer @ Sketchfab
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Rationale for dropping ModuleImport syntax?
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Matthew Robb matthewwr...@gmail.com Transpile aside, I don't want that performance concern. Most of the time I want a real solid reference and the only way to get it as the spec stands is to import something and then cache it locally. Isn't that kind of crazy? I don't know what performance concern you're referring to (probably a transpiler-only thing). But yes, I agree that it's crazy that you can't get solid references that you control (instead of aliasing bindings that the model author controls) without such shenanigans. I brought up that point [a long time ago](http://esdiscuss.org/topic/import-and-aliasing-bindings), and was told that we wanted to follow Scheme and ML instead of existing JS module systems. Which goes back to my frankly confounding comment from earlier... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
On Wed, Jun 11, 2014 at 4:39 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss es-discuss-boun...@mozilla.org on behalf of Matthew Robb matthewwr...@gmail.com Transpile aside, I don't want that performance concern. Most of the time I want a real solid reference and the only way to get it as the spec stands is to import something and then cache it locally. Isn't that kind of crazy? I don't know what performance concern you're referring to (probably a transpiler-only thing). But yes, I agree that it's crazy that you can't get solid references that you control (instead of aliasing bindings that the model author controls) without such shenanigans. I brought up that point [a long time ago](http://esdiscuss.org/topic/import-and-aliasing-bindings), and was told that we wanted to follow Scheme and ML instead of existing JS module systems. Which goes back to my frankly confounding comment from earlier... The answer you actually got when you asked this from Andreas expresses it very nicely: http://esdiscuss.org/topic/import-and-aliasing-bindings#content-1 Scheme and ML were only brought up when _you_ asked about other language's module systems. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
On Wed, Jun 11, 2014 at 1:25 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I have been working extensively with modules in a project that will be
going live this year. I am using traceur and I find myself often doing the
following:
module fs from fs;
var { readFile } = fs;
OR
import { readFile as _readFile } from fs;
var
readFile = _readFile;
It's partially due to the way module's get transpiled, if I were to just
do `import { readFile } from fs` then every reference to readFile in the
source ends up looking like `deps[0][readFile]()`
Transpile aside, I don't want that performance concern. Most of the time I
want a real solid reference and the only way to get it as the spec stands
is to import something and then cache it locally. Isn't that kind of crazy?
- Matthew Robb
On Wed, Jun 11, 2014 at 12:54 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith zenpars...@gmail.com
wrote:
Well, you're assuming exactly the state of affairs that this thread is
questioning... The fact that the threat of changing things to this
degree
has dredged up such polarized opinions should indicate that we ought to
be
leaving things alone.
...or that the compromise is making nobody happy, in which case
perhaps we've be better off with a simpler design which at least
*some* people really liked?
I don't know. My personal opinion is that the modules stuff still
feels like the odd duck which is being shoved into ES6 even though
it's not quite ready yet. But I'm hoping it all works out in the
end...
--scott
___
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: Rationale for dropping ModuleImport syntax?
On Wed, Jun 11, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote: The Traceur project would be interested in your issues and in a discussion on how to improve. Improvements are easy to try. jjb No matter what improvements could be made you are always going to have a slower, less performant program if every access to the imported identifiers has to do a value lookup operation. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
On 11 June 2014 14:01, Matthew Robb matthewwr...@gmail.com wrote: On Wed, Jun 11, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote: The Traceur project would be interested in your issues and in a discussion on how to improve. Improvements are easy to try. jjb No matter what improvements could be made you are always going to have a slower, less performant program if every access to the imported identifiers has to do a value lookup operation. This transpiler lookup only applies when ensuring the live binding support for exports. The output being referred to is not yet fully performance-optimized, and that is because we have prioritised completeness currently, ensuring exact circular reference and binding support. Thanks for bringing it up, as the work at the transpiler level does need to shift towards performance now that completeness has been covered, but this is very much a transpiler-level concern, unrelated to the spec. ___ 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: Rationale for dropping ModuleImport syntax?
Everyone just needs to chill out - ES6 modules are well-designed (thanks to Sam and Dave and Andreas and maybe myself a little ; ) and they are going to work extremely well in the field. The message needs to be that modules are *done*. Period. (Minus some minor cosmetic issues, perhaps.) Opening up this can of worms at the last TC39 meeting was a big mistake. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
Kevin, although I agree that ES6 modules are well-designed, I don't think the checkpoint that we did last week was a mistake, in fact, we invited implementers of the polyfills and transpilers to share their concerns and questions, to help us to correct course, that's all it was. Saying that the `moduleImport` syntax was not confusing and we should not change it is just saying that TC39 is not open for feedback, there is a clear problem with that, and you can see it in the way people are trying to use it, (e.g.: http://normalize.github.io/#transformations, check the way those folks are using the imported module as a function), and believe me, there are many more people using it wrong, because it is just confusing, that's all. we see this very often when people are asking questions during trainings/workshops and opening bugs for the transpilers and polyfills. The question is, what are we going to do about it? /caridy On Wed, Jun 11, 2014 at 7:21 PM, Kevin Smith zenpars...@gmail.com wrote: Everyone just needs to chill out - ES6 modules are well-designed (thanks to Sam and Dave and Andreas and maybe myself a little ; ) and they are going to work extremely well in the field. The message needs to be that modules are *done*. Period. (Minus some minor cosmetic issues, perhaps.) Opening up this can of worms at the last TC39 meeting was a big mistake. ___ 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: Module import syntax (leading / trailing from)
I think I was still using tabs when I've written a semantic import that
used from upfront [1]
However, it depends how you look at your imports ... when you read
import { _ } from
import { $ } from
import { gzip } from
you realize you don't even need to know where does that come from since the
semantic name used with the import is what you are looking for your script,
not in your folder structures.
+1 for the current `import { A } from I don't really care where A comes
from`
My 2cents
[1] http://webreflection.blogspot.com/2007/04/semantic-import.html
On Wed, Jun 11, 2014 at 1:28 PM, Maël Nison nison.m...@gmail.com wrote:
Hi,
It's probably too late to raise an objection, but anyway.
I've tried to find out the rational for the import [...] from [...]
syntax (rather than the common from [...] import [...]), and only found
the following old thread :
http://esdiscuss.org/topic/simpler-sweeter-syntax-for-modules, especially
this sentence :
I came to this because earlier versions of the syntax were inconsistent
about whether from meant the-module-itself or an-export-of-the-module,
which made it even more confusing. This new syntax was inspired by Python,
but with import as the leading keyword, rather than from. Which is what
leads to the inversion of order.
However, I'm still not quite sure to understand why is the import key
leading here. It sounds definitely better when speaking (since it's correct
valid english), but I don't find it very nice when wrote in a source code.
For example, I've got a lot of source code in multiple languages where the
imports are sorted according to their categories (vendors / app) and name,
ie something like :
define( [
'vendors/Backbone,
'vendors/Underscore',
'vendors/JQuery',
'models/Note',
'models/Users',
'views/Note',
'views/User',
'settings'
], [...] )
Using the ES6 syntax, however, comes to :
import { Backbone } from 'vendors/Backbone';
import { _ }from 'vendors/Underscore';
import { $ }from 'vendors/JQuery';
import { NoteModel : Note, UserModel : User } from 'models';
import { NoteView : Note, UserView : View } from 'views';
import { MAX_NOTES } from 'settings';
The pythonic syntax (leading from) would have been
from 'vendors/Backbone' import { Backbone };
from 'vendors/Underscore' import { _ };
from 'vendors/JQuery' import { $ };
from 'models' import { NoteModel : Note, UserModel : User };
from 'views'import { NoteView : Note, UserView : User };
from 'settings' import { MAX_NOTES };
Which, I think, is clearer : the reader knows what are the components used
by the module at the first glance. A trailing from sounds more difficult
to read, since it may be at the right of the screen (or even hidden
depending on the screen width).
I would also argue that knowing the module is more important than knowing
the symbols, since multiple modules can export the same symbols, and then
the reader has to parse the destructuring import to know what is the symbol
purpose (or look at the right).
Finally, symbols are often added / removed in a source code. However, a
module name doesn't often change. Using a trailing from may be a burden
for OCD-driven developers who like to keep some kind of indentation inside
their code.
import { NoteModel : Note, UserModel : User } from 'models';
import { MAX_NOTES } from 'settings';
Which becomes after a new feature
import { NoteModel : Note, UserModel : User, ReferenceModel :
Reference } from 'models';
import { MAX_NOTES }
from 'settings';
Then again after a refactoring
import { BookModel : Book, UserModel : User } from 'models';
import { MAX_NOTES } from 'settings';
The issue also arises in some extreme cases (this example comes from
Traceur) :
import { ARGUMENT_LIST, ARRAY_LITERAL_EXPRESSION, BINARY_OPERATOR,
BINDING_IDENTIFIER, CALL_EXPRESSION, [...], PAREN_EXPRESSION,
PROPERTY_NAME_ASSIGNMENT, REST_PARAMETER, SYNTAX_ERROR_TREE } from
'./trees/ParseTreeType';
In such a case, it's not very clear which is the module holding those
symbols (our eyes are trained to read from the top to the bottom, and I
think there's also a pythonic legacy which attracts the eyes at the top to
find the module name).
That's a purely cosmethic note, and I'm very satisfied by the current
direction of ES6; I was just wondering if this point had been discussed
before.
Thanks,
--
Maël Nison (arcanis https://twitter.com/arcanis)
Frontend Developer @ Sketchfab
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
Re: Rationale for dropping ModuleImport syntax?
Thanks Caridy, Please forgive my occasional hyperbole, I think es-discuss is best served with a dash of spice now and then. : ) I agree that the current design is somewhat confusing. That's because it represents a perfectly balanced compromise between the multi-export, remote-binding design favored by PL-types, and the single-export design favored by developers accustomed to Node.js and AMD. That duality is inherent in the design, and it is critical for its acceptance among all parties. Removing ModuleImport, in effect, tips that balance away from multi-exports and jeopardizes the compromise, and jeopardizes the effort. The inherent duality and resulting confusion should be left to evolution to work out. Supporting both outcomes (or a mixture thereof) is a feature, not a bug. That's my take, anyway. On the other hand, the lack of __dirname, etc. was a major hole and thank you for addressing it! Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
For anyone interested in the transpiler story around the existing spec I opened an issue here: https://github.com/google/traceur-compiler/issues/1072 - Matthew Robb On Wed, Jun 11, 2014 at 5:43 PM, Kevin Smith zenpars...@gmail.com wrote: Thanks Caridy, Please forgive my occasional hyperbole, I think es-discuss is best served with a dash of spice now and then. : ) I agree that the current design is somewhat confusing. That's because it represents a perfectly balanced compromise between the multi-export, remote-binding design favored by PL-types, and the single-export design favored by developers accustomed to Node.js and AMD. That duality is inherent in the design, and it is critical for its acceptance among all parties. Removing ModuleImport, in effect, tips that balance away from multi-exports and jeopardizes the compromise, and jeopardizes the effort. The inherent duality and resulting confusion should be left to evolution to work out. Supporting both outcomes (or a mixture thereof) is a feature, not a bug. That's my take, anyway. On the other hand, the lack of __dirname, etc. was a major hole and thank you for addressing it! Kevin ___ 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
