Re: System.import()?
I think a nice syntax would be allowing you to CALL import as a function from within function bodies to get contextual dynamic loading that is still SORT OF analyzable. It would also be nice if these import calls could SOMEHOW work like async function calls and not require direct interaction with a promise or callback. But I just work up so I may still be dreaming. - Matthew Robb On Wed, Aug 19, 2015 at 6:46 AM, Guy Bedford guybedf...@gmail.com wrote: It's great to see more interest in dynamic loading here. The contextual loader may be worth considering as a focus here - this is the special contextual loading syntax to effectively provide a scoped System.import call whose referrer is locked to the current module (`import module from this` as Dave has put in the roadmap, but I'm not sure what the exact syntax proposal is). This is the equivalent of the dynamic require in Node. As syntax it seems that would be in ECMA-262, and also might avoid the async Promise issues to share with Node as it can be entirely implementation-specific. Having a spec for this syntax would certainly be beneficial as it would immediately enable transpilers and module loading environments to then provide the dynamic loading feature, without other specification effort necessary. On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows isiahmead...@gmail.com wrote: There are ways for syncing promises for Node compatibility, although they all lie in C++ land. Similar has already been done with Node callbacks. https://www.npmjs.com/package/sync (You could also spawn a thread, block for a message, and join it with the promise result from a C++ callback from a thenable.) On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote: The problem is timing; WHATWG uses promises, which Node cannot use due to existing code bases on npm + potential mixing w/ `require`. This causes time discrepancies and would mean different actions depending on how exactly hooks are specced out. Node does not want to prevent async loading on the browser, and the WHATWG loader does not want to cause breakage in Node. On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote: This would assume they can support the transformation hooks to do things like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and ways of customizing that capability later. -j ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import()?
We have discussed the issue somewhat at length with the WHATWG loader spec with calls. We agree that having diverging async/sync properties is problematic if a feature is present in both Node and the browser. * the consensus is `System.import` returns a `Promise`, which means the execution of the load can always be done during the promise job queue. * Loader hooks for fetch/transformation/execution are left unspecified in terms of async/sync * * this delegates the branching logic from the Loader spec to the Loader implementation and creators of Loader hooks, metadata can be provided to feature detect what kind of Loader it is * using co-routines/non-typical JS can be avoided and any potential compatibility problems with VMs can be avoided as well. * * also avoids some VM limitations about only being able to materialize objects on the VM thread * new syntax is the branching for breaking changes * * opt-in of ES6 modules changes the loading order for modules for Node, but execution order can be kept consistent with what an async loader would perform * * circular bindings are an error (not circular dependencies) * `System.import` is still able to use `require` in node and preserve blocking nature some modules expect/require. * there is some inconsistency currently about when user `Promises` resolve *during* code loading, these should be looked into more A decent amount of information is not fleshed out in the spec / is discussed via email, so I would suggest moving to issues on the WHATWG Loader's github: https://github.com/whatwg/loader Until Loader is in a decent enough shape that both Node and WHATWG give it a thumbs up, I would wait. On Wed, Aug 19, 2015 at 3:38 AM, Isiah Meadows isiahmead...@gmail.com wrote: There are ways for syncing promises for Node compatibility, although they all lie in C++ land. Similar has already been done with Node callbacks. https://www.npmjs.com/package/sync (You could also spawn a thread, block for a message, and join it with the promise result from a C++ callback from a thenable.) On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote: The problem is timing; WHATWG uses promises, which Node cannot use due to existing code bases on npm + potential mixing w/ `require`. This causes time discrepancies and would mean different actions depending on how exactly hooks are specced out. Node does not want to prevent async loading on the browser, and the WHATWG loader does not want to cause breakage in Node. On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote: This would assume they can support the transformation hooks to do things like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and ways of customizing that capability later. -j ___ 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
Reified lvalue (was: Re: Extensible destructuring proposal)
Bergi wrote:
Samuel Hapák schrieb:
The main idea is, that if object defines `Symbol.get` method, it gets
used to access properties of object instead of `[]` when destructuring.
Aw, when I read extensible destructuring I had hoped to see an
extension to the destructuring syntax, not to see how semantics of
destructuring objects are changed.
What do you think about extractor functions, like in Scala
http://www.scala-lang.org/old/node/112?
Instead of `unapply` or `unapplySeq` methods we'd probably use an
`@@extractor` (`Symbol.extractor`) method or so, allowing us to do
let Map({a, b, c}) = myMap;
let List(a, b, c) = myList;
const Map({author: Map({name: {first, last}, birthdate})}) = book;
which would desugar to
let [{a, b, c}] = Map[Symbol.extractor](myMap);
let [a, b, c] = List[Symbol.extractor](myList);
const [{author: __author}] = Map[Symbol.extractor](book);
const [{name: {first, last}, birthdate}] = Map[Symbol.extractor](__author);
where each extractor method would return an Iterable that is assigned to
the arguments of the extractor. (A Proxy to lazily destructure object
literals in there is a good idea, thanks @Claude).
This would even allow us to call functions on destructuring, think about
module imports:
// a.js
export default function factory(options) {
…
return moduleInstance;
}
// b.js
const NoOptions = {
[Symbol.extractor](factory) { return [factory()]; }
};
const WithOptions = (...args) = ({
[Symbol.extractor](factory) { return [factory(...args)]; }
});
import NoOptions(A) from a;
import WithOptions(config)(A) from a;
// A === moduleInstance
What do you think about that?
Nice, but as Samuel mentioned, you need to actually transform the data
so it can be fed to stock destructurer.
What I came up is the idea of reified lvalue, the object that
describes the (complex, destucturing) lvalue used for assignment (for
example as the list of simple expression assignments, internally); and
that such object could be transformed.
Like (very rough examples; just an idea, not the spec):
let a = 4;
outer a - input
let {a,c:{b}} = foo;
outer a - input.a
tmp0 - input.c
outer b - tmp0.b
let {a,c:Map({b})} = foo;
Map[Symbol.lvalue] gets outer b - input.b and transforms it to
outer b - input.get('b'), so the result would be:
outer a - input.a
tmp0 - input.c
outer b - tmp0.get('b')
let Map(a,c:Map({b})) = foo;
Map[Symbol.lvalue] get the above descriptor and transforms it to
outer a - input.get('a')
tmp0 - input.get('c')
outer b - tmp.get('b')
If things like Map[Symbol.lvalue] would be frozen (or just speculatively
supposed not to be mutated), this can as well be done at compile time,
so the resulting code could stay fast.
Bergi
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Better place for discussion?
Is there a better place than this list to ask design questions that cover current best practice, upcoming features, and possible improvements to the language? e.g. I have found myself oft implementing function decorators and other mods to basic function behavior. I'm sure that my implementation could be improved and would be interested in feedback. But I'd also be interested in discussion of how the language is evolving to make it easier. Thanks, Michael McGlothlin Sent from my iPhone ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Existential Operator / Null Propagation Operator
What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. ! in this context typically means non-optional, or throw if the value is nill. See Swift for example. Or just `a!.b`? Same thing. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Existential Operator / Null Propagation Operator
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import()?
I'd like to see a general horn-clause style dependency resolution system built into JavaScript functions and see that applied to dynamic loading. Then the same system could be used to executing async operations smoothly, logic programming, etc. Something smart enough to resolve all the relationships from simple rules and lazy load the required bits as soon as possible. I've done that with running async code and it makes more sense to me than Promises. Michael McGlothlin On Aug 19, 2015, at 5:46 AM, Guy Bedford guybedf...@gmail.com wrote: It's great to see more interest in dynamic loading here. The contextual loader may be worth considering as a focus here - this is the special contextual loading syntax to effectively provide a scoped System.import call whose referrer is locked to the current module (`import module from this` as Dave has put in the roadmap, but I'm not sure what the exact syntax proposal is). This is the equivalent of the dynamic require in Node. As syntax it seems that would be in ECMA-262, and also might avoid the async Promise issues to share with Node as it can be entirely implementation-specific. Having a spec for this syntax would certainly be beneficial as it would immediately enable transpilers and module loading environments to then provide the dynamic loading feature, without other specification effort necessary. On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows isiahmead...@gmail.com wrote: There are ways for syncing promises for Node compatibility, although they all lie in C++ land. Similar has already been done with Node callbacks. https://www.npmjs.com/package/sync (You could also spawn a thread, block for a message, and join it with the promise result from a C++ callback from a thenable.) On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote: The problem is timing; WHATWG uses promises, which Node cannot use due to existing code bases on npm + potential mixing w/ `require`. This causes time discrepancies and would mean different actions depending on how exactly hooks are specced out. Node does not want to prevent async loading on the browser, and the WHATWG loader does not want to cause breakage in Node. On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote: This would assume they can support the transformation hooks to do things like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and ways of customizing that capability later. -j ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Existential Operator / Null Propagation Operator
In TypeScript `?` means optional. But throw if the value is nil is the same same as non-nullable? On Wed, Aug 19, 2015 at 9:24 PM, Kevin Smith zenpars...@gmail.com wrote: What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. ! in this context typically means non-optional, or throw if the value is nill. See Swift for example. Or just `a!.b`? Same thing. Kevin -- Sincerely, Tingan Ho @tingan87 https://twitter.com/tingan87 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better place for discussion?
Is there a better place than this list to ask design questions that cover current best practice, upcoming features, and possible improvements to the language? We don't generally cover best-practice or programming advice here, but obviously anything to do with extending the language or filling gaps is welcome. Proposals should be well-thought out, but questions can be short and quick. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import()?
On Tue, Aug 18, 2015 at 1:36 PM, Dave Herman dher...@mozilla.com wrote: The `System.loader.import` feature isn't ready for stabilization yet, and is blocked on a few other pieces of the Loader design. Well, if it isn't ready, it isn't ready. But can you tell a little bit more? What sort of changes are anticipated? Apart from System apparently being renamed, the API doesn't seem to have changed in the past few years. https://github.com/whatwg/loader/blob/master/roadmap.md Cool. Is the intent to release a standard as each stage of work is finished? Or will everything remain unstable until stage 3 is completed? -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Existential Operator / Null Propagation Operator
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. 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
Re: System.import()?
It's great to see more interest in dynamic loading here. The contextual loader may be worth considering as a focus here - this is the special contextual loading syntax to effectively provide a scoped System.import call whose referrer is locked to the current module (`import module from this` as Dave has put in the roadmap, but I'm not sure what the exact syntax proposal is). This is the equivalent of the dynamic require in Node. As syntax it seems that would be in ECMA-262, and also might avoid the async Promise issues to share with Node as it can be entirely implementation-specific. Having a spec for this syntax would certainly be beneficial as it would immediately enable transpilers and module loading environments to then provide the dynamic loading feature, without other specification effort necessary. On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows isiahmead...@gmail.com wrote: There are ways for syncing promises for Node compatibility, although they all lie in C++ land. Similar has already been done with Node callbacks. https://www.npmjs.com/package/sync (You could also spawn a thread, block for a message, and join it with the promise result from a C++ callback from a thenable.) On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote: The problem is timing; WHATWG uses promises, which Node cannot use due to existing code bases on npm + potential mixing w/ `require`. This causes time discrepancies and would mean different actions depending on how exactly hooks are specced out. Node does not want to prevent async loading on the browser, and the WHATWG loader does not want to cause breakage in Node. On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote: This would assume they can support the transformation hooks to do things like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and ways of customizing that capability later. -j ___ 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: Re: Existential Operator / Null Propagation Operator
One thing to keep in mind is that with prefix operator `?a.b` will also let people move back and forth with their caret. Since most people type the identifier first and then the operator. So they type `a` first and the move the caret in front of `a` and type `?` and then move the caret back to the last position and then type `.b`. This has been a big problem in typing type assertions in TS which had a prefix operator. They later introduced the `as` operator which is a postfix operator. What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. So the semantics of `a!?.` is `is it not null then the accessor ...`. Or just `a!.b`? [1]: Non-nullable type — http://usejsdoc.org/tags-type.html -- Sincerely, Tingan Ho @tingan87 https://twitter.com/tingan87 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import()?
There are ways for syncing promises for Node compatibility, although they all lie in C++ land. Similar has already been done with Node callbacks. https://www.npmjs.com/package/sync (You could also spawn a thread, block for a message, and join it with the promise result from a C++ callback from a thenable.) On Tue, Aug 18, 2015, 18:06 Bradley Meck bradley.m...@gmail.com wrote: The problem is timing; WHATWG uses promises, which Node cannot use due to existing code bases on npm + potential mixing w/ `require`. This causes time discrepancies and would mean different actions depending on how exactly hooks are specced out. Node does not want to prevent async loading on the browser, and the WHATWG loader does not want to cause breakage in Node. On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote: This would assume they can support the transformation hooks to do things like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and ways of customizing that capability later. -j ___ 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: Re: Existential Operator / Null Propagation Operator
-1 for the `!` idea. It feels redundant to me, since if you try calling an undefined value, it'll throw errors at you. It doesn't seem to insure anything extra beyond current behavior. On Wed, Aug 19, 2015, 02:27 Tingan Ho tinga...@gmail.com wrote: One thing to keep in mind is that with prefix operator `?a.b` will also let people move back and forth with their caret. Since most people type the identifier first and then the operator. So they type `a` first and the move the caret in front of `a` and type `?` and then move the caret back to the last position and then type `.b`. This has been a big problem in typing type assertions in TS which had a prefix operator. They later introduced the `as` operator which is a postfix operator. What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. So the semantics of `a!?.` is `is it not null then the accessor ...`. Or just `a!.b`? [1]: Non-nullable type — http://usejsdoc.org/tags-type.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: Re: Existential Operator / Null Propagation Operator
I don't see the redundancy? In my proposal the original proposed symbol `?` is switched with `!`. So it shouldn't throw any error? On Wed, Aug 19, 2015 at 4:42 PM, Isiah Meadows isiahmead...@gmail.com wrote: -1 for the `!` idea. It feels redundant to me, since if you try calling an undefined value, it'll throw errors at you. It doesn't seem to insure anything extra beyond current behavior. On Wed, Aug 19, 2015, 02:27 Tingan Ho tinga...@gmail.com wrote: One thing to keep in mind is that with prefix operator `?a.b` will also let people move back and forth with their caret. Since most people type the identifier first and then the operator. So they type `a` first and the move the caret in front of `a` and type `?` and then move the caret back to the last position and then type `.b`. This has been a big problem in typing type assertions in TS which had a prefix operator. They later introduced the `as` operator which is a postfix operator. What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. So the semantics of `a!?.` is `is it not null then the accessor ...`. Or just `a!.b`? [1]: Non-nullable type — http://usejsdoc.org/tags-type.html -- Sincerely, Tingan Ho @tingan87 https://twitter.com/tingan87 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Sincerely, Tingan Ho @tingan87 https://twitter.com/tingan87 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Reified lvalue (was: Re: Extensible destructuring proposal)
I know this is pointless bikeshedding, but that particular operator
conflicts with a current valid production.
```js
// These are synonymous, and are
// valid statements
tmp0 - input.get('c')
tmp0 (-input.get('c'))
```
On Wed, Aug 19, 2015, 09:53 Herby Vojčík he...@mailbox.sk wrote:
Bergi wrote:
Samuel Hapák schrieb:
The main idea is, that if object defines `Symbol.get` method, it gets
used to access properties of object instead of `[]` when destructuring.
Aw, when I read extensible destructuring I had hoped to see an
extension to the destructuring syntax, not to see how semantics of
destructuring objects are changed.
What do you think about extractor functions, like in Scala
http://www.scala-lang.org/old/node/112?
Instead of `unapply` or `unapplySeq` methods we'd probably use an
`@@extractor` (`Symbol.extractor`) method or so, allowing us to do
let Map({a, b, c}) = myMap;
let List(a, b, c) = myList;
const Map({author: Map({name: {first, last}, birthdate})}) = book;
which would desugar to
let [{a, b, c}] = Map[Symbol.extractor](myMap);
let [a, b, c] = List[Symbol.extractor](myList);
const [{author: __author}] = Map[Symbol.extractor](book);
const [{name: {first, last}, birthdate}] =
Map[Symbol.extractor](__author);
where each extractor method would return an Iterable that is assigned to
the arguments of the extractor. (A Proxy to lazily destructure object
literals in there is a good idea, thanks @Claude).
This would even allow us to call functions on destructuring, think about
module imports:
// a.js
export default function factory(options) {
…
return moduleInstance;
}
// b.js
const NoOptions = {
[Symbol.extractor](factory) { return [factory()]; }
};
const WithOptions = (...args) = ({
[Symbol.extractor](factory) { return [factory(...args)]; }
});
import NoOptions(A) from a;
import WithOptions(config)(A) from a;
// A === moduleInstance
What do you think about that?
Nice, but as Samuel mentioned, you need to actually transform the data
so it can be fed to stock destructurer.
What I came up is the idea of reified lvalue, the object that
describes the (complex, destucturing) lvalue used for assignment (for
example as the list of simple expression assignments, internally); and
that such object could be transformed.
Like (very rough examples; just an idea, not the spec):
let a = 4;
outer a - input
let {a,c:{b}} = foo;
outer a - input.a
tmp0 - input.c
outer b - tmp0.b
let {a,c:Map({b})} = foo;
Map[Symbol.lvalue] gets outer b - input.b and transforms it to
outer b - input.get('b'), so the result would be:
outer a - input.a
tmp0 - input.c
outer b - tmp0.get('b')
let Map(a,c:Map({b})) = foo;
Map[Symbol.lvalue] get the above descriptor and transforms it to
outer a - input.get('a')
tmp0 - input.get('c')
outer b - tmp.get('b')
If things like Map[Symbol.lvalue] would be frozen (or just speculatively
supposed not to be mutated), this can as well be done at compile time,
so the resulting code could stay fast.
Bergi
Herby
___
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
Take props from object
Hey guys,
From an internal conversation, we've received a question, and as a follow
up, the proposal of take needed props from an object.
Currently if you need to take some properties from an object, you'd do:
```javascript
var foo = {x: bar.x, y: bar.y, z: bar.z};
```
With possible shorthand it even could be (I guess someone proposed this
already at some point):
```javascript
var foo = {bar.x, bar.y, bar.z};
```
Sometimes one could also do with destructuring and shorhands, but these are
two actions
```javascript
var {x, y, z} = bar;
var foo = {x, y, z};
```
And the take props operator combine those approaches, and may look like
an import statement from a module, just without the `import` keyword:
```javascript
var foo = {x, y, z} from bar;
```
I personally liked this strawman, it smoothes the border between a module
and an object (which is also a module/namespace, from which we can import
needed exports).
I haven't checked yet the grammar, seems should be fine from the first
glance.
Thoughts?
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Take props from object
On Wed, Aug 19, 2015 at 9:22 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
```javascript
var foo = {x, y, z} from bar;
```
I haven't checked yet the grammar, seems should be fine from the first
glance.
Yeah, it should be parsed first as an object literal, and then to the take
props operator if the lookahead is `from`.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
