Re: System.import()?
Jason, I agree with you that there needs to be making rapid progress with the dynamic module API. I also think, that TC39 need to be full engaged with the design of that API. However, I have some issues with the specifics you defined below. My over-riding concern is that we don't loose from the specification the ability to do static, ahead-of-time module linking for implementations and situations where all modules are know and available prior to program execution. Ahead-of-time lining was an important consideration for the structuring of ES6 clause 15.2.1 and I'd hate to see us go backwards in that regard (instead I think that we should refractor ModuleDeclarationInstantiation (and Module Record) to clarify which parts of it can be performed during ahead-of-time linking). The key enabler for ahead-of-time linking is that the abstract operations and data structures required to specify module linking must not depend upon ES runtime values or runtime data structures. More specific concerns below On Aug 18, 2015, at 2:37 PM, Jason Orendorff wrote: On Tue, Aug 18, 2015 at 12:11 PM, Domenic Denicola d...@domenic.me wrote: HostResolveImportedModule is widely implemented by compilers, though not by browsers. People are writing, using, and sharing ES6 modules today. So what is your proposal then? Just standardize the node module resolution algorithm, since that is what transpilers are doing? Here's what I had in mind: * Do not standardize the Node algorithm or any other module loading algorithm in ECMA-262. That responsibility belongs to the Loader standard. agreed * Change the signature of HostResolveImportedModule to match `System.import()`, which takes a this-value and two strings (name and referrer). HostResovleImportedModule must be an ahead-of-time friendly abstract operation, hence it can't depend upon a this-value or any runtime value. It isn't clear to me why you think that parameter is needed. Changing the refer from a Module Record to a string would not create an ahead-of-time link issue, but I'm not sure why you think that is needed. * Clarify that HostResolveImportedModule (and its existing callers in the spec) operate asynchronously, e.g. by adding a PromiseCapability argument, like PerformPromiseAll. (The async functions proposal takes a different approach to specifying async algorithms, but I'm not sure if that's final wording or what exactly.) The linking algorithm (which is threaded through ModuleDeclarationInstantiation, that's what I think needs refactoring) calls HostResolveImportedModule and so it can't have any dependencies upon ES promises or any other ES runtime artifacts. The easy way to make module loading asynchronous (without adding runtime dependencies or complicating linking with async steps algorithm) is to define a Job (all ES Jobs are async) that performs the module loading steps. That's essentially what TopLevelModuleEvaluationJob does. A SystemLoad job would be similar, but could have additional steps that are specific to the semantics of dynamic module loading. * Specify a `System` builtin object. * Specify a builtin method System.import(name[, referrer]) that performs these steps: 1. Let promiseCapability be NewPromiseCapability(%Promise%). 2. Return HostResolveImportedModule(this value, name, referrer, promiseCapability). Nothing terribly exciting here. Some vaguely interesting refactoring in the second and third bullet points. I would do the equivalent via the DynamicModuleEvaluation Job: System.import (or whatever it is called)would: 1. Create a new PromiseCapability 2. Start a DynamicModuleEvaluation job, passing it the promise capability along with the user supplied arguments 3. Return the Promise object of the PromiseCapability The intent with `System.import()` all along was to provide a dynamic equivalent to the static `import` syntax. Why not go one step further and make it official that they share an implementation? That's all this proposal does, and that's enough to make a useful standard API for people who are writing ES6 modules right now. Fine, as long as we don't further muddle-up those parts of module linking/loading that don't have runtime dependencies with those that do. allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Existential Operator / Null Propagation Operator
On 19 August 2015 at 16:21, Tingan Ho tinga...@gmail.com wrote: Strange why do they need an operator for that? Probably to make it less error prone with access nil errors. But that could be fixed with static code analysis. OT but: The whole point of optional values (as opposed to null/nil/undefined inhabiting everything) is to make the boundaries of optionality explicit, thereby avoiding Hoare's billion dollar mistake. That said, convenient operators like ! already destroy half the benefit. Plenty of experience from other languages like ML or Haskell shows that they are almost always used incorrectly (read: over-optimistically). If a language has to have such an operator, it should at least be very explicit and as inconvenient as bearable. /Andreas On Wed, Aug 19, 2015 at 10:09 PM, Kevin Smith zenpars...@gmail.com wrote: In TypeScript `?` means optional. But throw if the value is nil is the same same as non-nullable? In Swift, the postfix ! operator unwraps an optional value, throwing if nil. See https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html -- Sincerely, Tingan Ho @tingan87 https://twitter.com/tingan87 ___ 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: Property ordering of [[Enumerate]] / getOwnPropertyNames()
On Aug 20, 2015, at 9:54 AM, Jesse McCarthy wrote: I just want to confirm some things about property enumeration order of plain Objects. I apologize that this has probably already been discussed before, but it's hard to locate a clear answer. Please note that I'm solely asking about ES2015 spec compliance, not what's in the wild. Given: ```js var y = Object.create(null); // Note that property names are all strings. y.one = 1; y.two = 2; y.three = 3; ``` This is my understanding of what's guaranteed (or not) about enumeration order (in the context of the example given): 1. No guarantee of order Anything that relies on or has property-order equivalence with `[[Enumerate]]` or `EnumerableOwnNames` 1b. for (x in y) 1c. Object.keys(y) This is based on the statement in 9.1.11 [[Enumerate]] () step 1: The mechanics and order of enumerating the properties is not specified Although it says that... [[Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method. ...and `[[OwnPropertyKeys]]` specifies ordering, my reading is that `[[Enumerate]]` doesn't guarantee that the iterator it returns will preserve the order returned by `[[OwnPropertyKeys]]`. Correct. Historically, the for-in order was not defined and there has been variation among browser implementations in the order they produce.(and other specifics). ES5 added Object.keys and the requirement that it should order the keys identically to for-in. During development of both ES5 and ES6 the possibility of defining a defining a specific for-in order was considered but not adopted because of web legacy compatibility concerns and uncertainly about the willingness of browsers to make changes in the ordering they currently produce. If we decided to specify the for-in order it would be the order produced by the informative algorithm provided in 9.1.11. As a step in that direction, we should consider for ES7 adding to 9.1.11 something like: If the target object's [[Prototype]] is null, then properties have the same relative ordering for both [[Enumerate]] and [[OwnPropertyKeys]] 2. Guarantee of insertion order (['one', 'two', 'three']) Object.getOwnPropertyNames(y) yes Are those interpretations correct? Related: In this thread... https://esdiscuss.org/topic/nailing-object-property-order ...Bergi asked these pertinent questions that no one answered: But why was the default object [[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]] order then? ... Shouldn't we add a guarantee to [[enumerate]] that the subset of enumerated own properties comes in insertion order as well? legacy concerns, see above and numerous historic es-discuss threads Allen This is partly in reference to http://stackoverflow.com/a/30244410/1034448 ___ 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
Property ordering of [[Enumerate]] / getOwnPropertyNames()
I just want to confirm some things about property enumeration order of plain Objects. I apologize that this has probably already been discussed before, but it's hard to locate a clear answer. Please note that I'm solely asking about ES2015 spec compliance, not what's in the wild. Given: ```js var y = Object.create(null); // Note that property names are all strings. y.one = 1; y.two = 2; y.three = 3; ``` This is my understanding of what's guaranteed (or not) about enumeration order (in the context of the example given): 1. No guarantee of order Anything that relies on or has property-order equivalence with `[[Enumerate]]` or `EnumerableOwnNames` 1b. for (x in y) 1c. Object.keys(y) This is based on the statement in 9.1.11 [[Enumerate]] () step 1: The mechanics and order of enumerating the properties is not specified Although it says that... [[Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method. ...and `[[OwnPropertyKeys]]` specifies ordering, my reading is that `[[Enumerate]]` doesn't guarantee that the iterator it returns will preserve the order returned by `[[OwnPropertyKeys]]`. 2. Guarantee of insertion order (['one', 'two', 'three']) Object.getOwnPropertyNames(y) Are those interpretations correct? Related: In this thread... https://esdiscuss.org/topic/nailing-object-property-order ...Bergi asked these pertinent questions that no one answered: But why was the default object [[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]] order then? ... Shouldn't we add a guarantee to [[enumerate]] that the subset of enumerated own properties comes in insertion order as well? This is partly in reference to http://stackoverflow.com/a/30244410/1034448 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()
This doesn't answer the spec question, exactly, but v8 doesn't currently conform to ES6's requirements for [[OwnPropertyKeys]]: some objects return names in an implementation-dependent order (see https://code.google.com/p/v8/issues/detail?id=3056 for more details). On Thu, Aug 20, 2015 at 9:54 AM, Jesse McCarthy es-discuss-2015...@jessemccarthy.net wrote: I just want to confirm some things about property enumeration order of plain Objects. I apologize that this has probably already been discussed before, but it's hard to locate a clear answer. Please note that I'm solely asking about ES2015 spec compliance, not what's in the wild. Given: ```js var y = Object.create(null); // Note that property names are all strings. y.one = 1; y.two = 2; y.three = 3; ``` This is my understanding of what's guaranteed (or not) about enumeration order (in the context of the example given): 1. No guarantee of order Anything that relies on or has property-order equivalence with `[[Enumerate]]` or `EnumerableOwnNames` 1b. for (x in y) 1c. Object.keys(y) This is based on the statement in 9.1.11 [[Enumerate]] () step 1: The mechanics and order of enumerating the properties is not specified Although it says that... [[Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method. ...and `[[OwnPropertyKeys]]` specifies ordering, my reading is that `[[Enumerate]]` doesn't guarantee that the iterator it returns will preserve the order returned by `[[OwnPropertyKeys]]`. 2. Guarantee of insertion order (['one', 'two', 'three']) Object.getOwnPropertyNames(y) Are those interpretations correct? Related: In this thread... https://esdiscuss.org/topic/nailing-object-property-order ...Bergi asked these pertinent questions that no one answered: But why was the default object [[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]] order then? ... Shouldn't we add a guarantee to [[enumerate]] that the subset of enumerated own properties comes in insertion order as well? This is partly in reference to http://stackoverflow.com/a/30244410/1034448 ___ 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
