Re: Extensible destructuring proposal
I too am fond of Scala's extensible pattern matching. Before I knew about
Scala's approach, I thoughtlessly agreed with the conventional wisdom that
pattern matching and object-oriented programming are necessarily at odds.
Letting objects define their own destructuring semantics shows that wisdom
to be mistaken, and your Symbol.extractor method feels like a perfectly
ECMAScript-y way to implement it.
That said, virtually every time I've written an unapply or unapplySeq
method in Scala, it has been with multi-case pattern matching in mind, and
we're only talking about destructuring assignment here, which I suppose is
like a single-case pattern match.
If you have time/motivation to put together a proposal for
Symbol.extractor, I would very much encourage you to think about the
possibility of introducing multi-case pattern matching as well, as I think
that would add significant value to the proposal, as well as highlighting
some tricky issues.
I'd be happy to review and/or help champion such a proposal, if it works
out as nicely as I hope!
Ben
On Tue, Jul 21, 2015 at 10:23 AM Bergi a.d.be...@web.de 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?
Bergi
___
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: Extensible destructuring proposal
On 21.7.2015, at 16:23, Bergi a.d.be...@web.de wrote: 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. Thanks Bergi, I find your idea really interesting. If get it, benefit of your approach is that user explicitly specifies how to extract data instead of relying on extraction method defined by object being extracted. This way, you can create multiple competing extractors, so your solution is a lot more flexible than mine. Actually, mine proposal is just special case of yours. I could implement `E[@@extractor]` that just tries to find `__get__` method on object being extracted and uses it. The only downside I see is the verbosity. Could you please elaborate more on the use cases for this? I am not used to Scala so my imagination is currently very limited:) I know that I would really really need different destructuring for different object types (otherwise it is insanely verbose to use Immutable Maps), but I can’t think of use case for having multiple different destructurings for single type. Could you show some examples? Thanks! Samuel smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
On 21.7.2015, at 12:42, Claude Pache claude.pa...@gmail.com wrote:
For example, one can imagine something like:
```js
const {author: {name: {first, last}, birthdate}} = book.toObject()
```
There are two issues I see here:
- `book.toObject()` would have to do deep conversion and you may not want it.
Let’s say birthdate is immutable map `{day, month, year}`*. This would convert
`birthdate` to `Object` even though you didn’t want that.
- this can handle only String keys. My proposal could be extended so this would
work:
```js
const {[someNonStringKey]: value} = someMap;
```
We already have a syntax for that in es6.
PS: * I know we have `Date()` for that purpose. Just for demonstration.
Samuel
smime.p7s
Description: S/MIME cryptographic signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Extensible destructuring proposal
From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com]
Could you please explain it on example?
Let’s say I have
```
let book = Map{author: {name: “John”, surname: “Doe”}, birthdate:
“10-10-1990”};
```
How would you extract `birthdate`? How would you extract `name`?
Your syntax here is invalid in at least four different ways. Let's assume you
wrote something with valid syntax, like
```js
let book = new Map([[author, { name: John, surname: Doe }], [birthdate,
10-10-1990]]);
```
Then:
```js
const [[, { name }], [, birthdate]] = book.entries();
```
If this is still confusing, you may wish to turn to StackOverflow for
clarification, instead of es-discuss. You can test such things in Firefox,
although you need to use `var` instead of `const` or `let`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
Domenic Denicola schrieb: For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` The problem with this is that you would need to know the order of the keys in the map. Your code does only extract the first and second key-value pairs, allowing us to get the key values of them, but this syntax does not allow us to extract the value for a given key from somewhere in the map. Predictability is all fine, but I still consider maps to be inherently unordered. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
Samuel Hapák schrieb:
I find your idea really interesting. If get it, benefit of your approach is
that user explicitly specifies how to extract data instead of relying on
extraction method defined by object being extracted.
This way, you can create multiple competing extractors
That wasn't my primary goal (indeed most data structures would have only
a single extractor).
The main benefits I see are:
* explicit is better than implicit
* works anywhere in a destructuring pattern, not only the topmost level
* can be chosen not to be used (e.g. for `let {size} = myMap;`)
The only downside I see is the verbosity.
That's an advantage imo :-)
Could you show some examples? Thanks!
I don't think there's much more than the ones I already gave.
Notice that those `NoOptions` and `WithOptions()` was even an example
for multiple extractors to be used for destructuring factory functions
(by applying them), though I don't know whether that's the best solution
for this `import` problem.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
Well, the spec says they are ordered, so I'm not sure where you're getting that from. From: Bergi a.d.be...@web.de Sent: Jul 21, 2015 8:53 AM To: Domenic Denicola; es-discuss Subject: Re: Extensible destructuring proposal Domenic Denicola schrieb: For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` The problem with this is that you would need to know the order of the keys in the map. Your code does only extract the first and second key-value pairs, allowing us to get the key values of them, but this syntax does not allow us to extract the value for a given key from somewhere in the map. Predictability is all fine, but I still consider maps to be inherently unordered. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
Ben Newman schrieb: That said, virtually every time I've written an unapply or unapplySeq method in Scala, it has been with multi-case pattern matching in mind, and we're only talking about destructuring assignment here, which I suppose is like a single-case pattern match. Right, we don't really have pattern matching in ES yet. I don't want to introduce that as well, it would be a pretty heavy change imo. If you have time/motivation to put together a proposal for Symbol.extractor, I would very much encourage you to think about the possibility of introducing multi-case pattern matching as well, as I think that would add significant value to the proposal, as well as highlighting some tricky issues. I've seen that Scala returns an Option for a pattern. My first thought was to make @@extractor return an empty iterator, but I'm not sure whether that's semantically sound. We then could consider an iterator to be not matching if any of the target elements are left `undefined`, i.e. when the iterator is exhausted before all elements have gotten a value, similar to default initialisers are handled today. Do you think that is viable? Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
On 21.7.2015, at 15:09, Domenic Denicola d...@domenic.me wrote:
For maps you can just do
```js
const [[k1, v1], [k2, v2], ...rest] = map.entries();
```
There is no need to add more complexity to object destructuring (which should
only be used for objects and their string keys).
Could you please explain it on example?
Let’s say I have
```
let book = Map{author: {name: “John”, surname: “Doe”}, birthdate: “10-10-1990”};
```
How would you extract `birthdate`? How would you extract `name`?
Thanks,
Samuel
smime.p7s
Description: S/MIME cryptographic signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
I think the example actually reveals a deeper issue with the motivation: the desire to destructure maps like here is rooted in a category error. Destructuring is designed to apply to objects from the program domain, while maps are typically meant to encode data from the problem domain. Or, in other words: destructuring is only useful when you know the keys at programming time (i.e., statically). But if that is the case, there is rarely a good reason to use a map. /Andreas On 21 July 2015 at 18:12, Domenic Denicola d...@domenic.me wrote: Well, the spec says they are ordered, so I'm not sure where you're getting that from. *From:* Bergi a.d.be...@web.de *Sent:* Jul 21, 2015 8:53 AM *To:* Domenic Denicola; es-discuss *Subject:* Re: Extensible destructuring proposal Domenic Denicola schrieb: For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` The problem with this is that you would need to know the order of the keys in the map. Your code does only extract the first and second key-value pairs, allowing us to get the key values of them, but this syntax does not allow us to extract the value for a given key from somewhere in the map. Predictability is all fine, but I still consider maps to be inherently unordered. Bergi ___ 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: Extensible destructuring proposal
Domenic Denicola schrieb:
Well, the spec says they are ordered, so I'm not sure where you're getting
that from.
Yes, the spec defines an order to make iteration predictable and
consistent, but that doesn't mean anyone would use a `Map` for an
ordered structure. I would consider
new Map(Object.entries({a: 1, b: 2}))
and
new Map(Object.entries({b: 2, a: 1}))
to be equivalent for all purposes of an algorithm that uses commutative
operators.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
On 21.7.2015, at 17:19, Domenic Denicola d...@domenic.me wrote:
From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com]
Could you please explain it on example?
Let’s say I have
```
let book = Map{author: {name: “John”, surname: “Doe”}, birthdate:
“10-10-1990”};
```
How would you extract `birthdate`? How would you extract `name`?
Your syntax here is invalid in at least four different ways.
If this is still confusing, you may wish to turn to StackOverflow for
clarification, instead of es-discuss.
I apologize for the syntax mistakes I made. I totally understand you receive
tons of proposals from people who don’t bother to learn JavaScript. I
understand that this pissed you off and I am sorry for that. My bad.
Here is the valid syntax:
```js
let book = new Map([['author', Map([['name', 'John'], ['surname', 'Doe']]),
['birthdate', '10-10-1990']]);
let book2 = new Map([['birthdate', '10-10-1990'], ['author', Map([['name',
'John'], ['surname', 'Doe']])]]);
```
Now, I wish to extract `birthdate` and `name`. I can't rely on the order of
elements, because the code should accept any `book` that has same shape. Let's
say, ordering of the items in the map is not the part of the contract. So, to
clarify this, I want to write function that accepts `book` or `book2` and
inside, it extracts `birthdate` and `name`. The code should work with both
`book` and `book2`.
I feel, that your solution is unable to achieve this, but I can be mistaken.
Thanks!
Samuel
smime.p7s
Description: S/MIME cryptographic signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
On 21.7.2015, at 20:16, Andreas Rossberg rossb...@google.com wrote: Or, in other words: destructuring is only useful when you know the keys at programming time (i.e., statically). But if that is the case, there is rarely a good reason to use a map. Actually, the main motivation is to use Immutable Map (https://facebook.github.io/immutable-js/ https://facebook.github.io/immutable-js/). All examples shown here displayed only keys known statically (at programming time). I just mentioned that it could be nice to allow non-string keys and that we could reuse syntax that currently works for dynamic keys. But that definitely is not the core of the discussion here. Samuel smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.trimRight/trimLeft
They're already shipping with the wrong names in every browser. From: Norbert Lindenberg ecmascr...@lindenbergsoftware.com Sent: Jul 20, 2015 23:25 To: Dmitry Soshnikov Cc: Norbert Lindenberg; Domenic Denicola; es-discuss Subject: Re: String.prototype.trimRight/trimLeft These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here. Norbert On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote: Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)? People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Thanks! Dmitry On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote: OK, the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed. Dmitry On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov dmitry.soshni...@gmail.commailto:dmitry.soshni...@gmail.com wrote: Sounds good. Yeah, I'll spec it, and add the test. Dmitry On Tuesday, March 17, 2015, Domenic Denicola d...@domenic.memailto:d...@domenic.me wrote: Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations. Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4. From: es-discuss [mailto:es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry Soshnikov Sent: Wednesday, March 18, 2015 05:02 To: Tab Atkins Jr. Cc: es-discuss Subject: Re: String.prototype.trimRight/trimLeft Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec). I guess we just need to confirm it's good to go to ES7? Dmitry On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. jackalm...@gmail.commailto:jackalm...@gmail.com wrote: On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott leonarn...@gmail.commailto:leonarn...@gmail.com wrote: I believe opinion hasn't shifted since it was discussed [previously](https://esdiscuss.org/topic/standardizing-more-de-facto-functions) - in short, show me the cowpath. (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.) I use both lstrip() and rstrip() in Bikeshed (a Python project): https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying. ~TJ ___ es-discuss mailing list es-discuss@mozilla.orgmailto: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: String.prototype.trimRight/trimLeft
On the contrary -left always begins at index 0 - start is sometimes index 0, sometimes index (length - 1). I think left and right are the right names; start and end would require unicode bidirectional stuff. On Mon, Jul 20, 2015 at 11:25 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here. Norbert On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)? People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Thanks! Dmitry On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: OK, the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed. Dmitry On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Sounds good. Yeah, I'll spec it, and add the test. Dmitry On Tuesday, March 17, 2015, Domenic Denicola d...@domenic.me wrote: Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations. Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry Soshnikov Sent: Wednesday, March 18, 2015 05:02 To: Tab Atkins Jr. Cc: es-discuss Subject: Re: String.prototype.trimRight/trimLeft Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec). I guess we just need to confirm it's good to go to ES7? Dmitry On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott leonarn...@gmail.com wrote: I believe opinion hasn't shifted since it was discussed [previously]( https://esdiscuss.org/topic/standardizing-more-de-facto-functions) - in short, show me the cowpath. (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.) I use both lstrip() and rstrip() in Bikeshed (a Python project): https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying. ~TJ ___ 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: String.prototype.trimRight/trimLeft
Le 21 juil. 2015 à 08:28, Jordan Harband ljh...@gmail.com a écrit : On the contrary -left always begins at index 0 - start is sometimes index 0, sometimes index (length - 1). Counter-example: ES6 methods `String#startsWith` and `String#endsWith` are named correctly. I think left and right are the right names; start and end would require unicode bidirectional stuff. No, because characters in Unicode strings are ordered logically, not visually. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.trimRight/trimLeft
In which coordinate system? Norbert On Jul 20, 2015, at 23:28 , Jordan Harband ljh...@gmail.com wrote: On the contrary -left always begins at index 0 - start is sometimes index 0, sometimes index (length - 1). I think left and right are the right names; start and end would require unicode bidirectional stuff. On Mon, Jul 20, 2015 at 11:25 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here. Norbert On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)? People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Thanks! Dmitry On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: OK, the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed. Dmitry On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Sounds good. Yeah, I'll spec it, and add the test. Dmitry On Tuesday, March 17, 2015, Domenic Denicola d...@domenic.me wrote: Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations. Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry Soshnikov Sent: Wednesday, March 18, 2015 05:02 To: Tab Atkins Jr. Cc: es-discuss Subject: Re: String.prototype.trimRight/trimLeft Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec). I guess we just need to confirm it's good to go to ES7? Dmitry On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott leonarn...@gmail.com wrote: I believe opinion hasn't shifted since it was discussed [previously](https://esdiscuss.org/topic/standardizing-more-de-facto-functions) - in short, show me the cowpath. (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.) I use both lstrip() and rstrip() in Bikeshed (a Python project): https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying. ~TJ ___ 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
Extensible destructuring proposal
Hello there, I have written proposal to allow extend standard behavior of object destructuring: https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md Main idea is, that currently object destructuring is useless for people who use Map or Immutable.Map (https://facebook.github.io/immutable-js/) as their main data structure. This would allow authors of libraries to create map like structures that would support destructuring. It extends the language in a similar way iterator does. The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. What do you think? Cheers, Samuel smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
Le 21 juil. 2015 à 08:14, Samuel Hapák samuel.ha...@vacuumapps.com a écrit :
Hello there,
I have written proposal to allow extend standard behavior of object
destructuring:
https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md
Main idea is, that currently object destructuring is useless for people who
use Map or Immutable.Map (https://facebook.github.io/immutable-js/) as their
main data structure.
This would allow authors of libraries to create map like structures that
would support destructuring. It extends the language in a similar way
iterator does.
The main idea is, that if object defines `Symbol.get` method, it gets used to
access properties of object instead of `[]` when destructuring.
What do you think?
Cheers,
Samuel
An alternative to `Symbol.get` is a Proxy with a get trap. Maybe worth
experimenting with Proxies?
For example, one can imagine something like:
```js
const {author: {name: {first, last}, birthdate}} = book.toObject()
```
where `.toObject()` is a method returning a proxy, or, in implementations
lacking proxies, falling back to convert eagerly the structure into a plain
object.
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.trimRight/trimLeft
That’s very sad, because they’re wrong, not “wrong”. Norbert On Jul 20, 2015, at 23:29 , Domenic Denicola d...@domenic.me wrote: They're already shipping with the wrong names in every browser. From: Norbert Lindenberg ecmascr...@lindenbergsoftware.com Sent: Jul 20, 2015 23:25 To: Dmitry Soshnikov Cc: Norbert Lindenberg; Domenic Denicola; es-discuss Subject: Re: String.prototype.trimRight/trimLeft These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here. Norbert On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)? People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Thanks! Dmitry On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: OK, the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed. Dmitry On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Sounds good. Yeah, I'll spec it, and add the test. Dmitry On Tuesday, March 17, 2015, Domenic Denicola d...@domenic.me wrote: Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations. Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry Soshnikov Sent: Wednesday, March 18, 2015 05:02 To: Tab Atkins Jr. Cc: es-discuss Subject: Re: String.prototype.trimRight/trimLeft Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec). I guess we just need to confirm it's good to go to ES7? Dmitry On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott leonarn...@gmail.com wrote: I believe opinion hasn't shifted since it was discussed [previously](https://esdiscuss.org/topic/standardizing-more-de-facto-functions) - in short, show me the cowpath. (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.) I use both lstrip() and rstrip() in Bikeshed (a Python project): https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying. ~TJ ___ 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: String.prototype.trimRight/trimLeft
These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here. Norbert On Jul 20, 2015, at 15:09 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)? People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Thanks! Dmitry On Wed, Mar 18, 2015 at 2:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: OK, the spec is here: https://gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed. Dmitry On Tue, Mar 17, 2015 at 7:36 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Sounds good. Yeah, I'll spec it, and add the test. Dmitry On Tuesday, March 17, 2015, Domenic Denicola d...@domenic.me wrote: Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations. Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry Soshnikov Sent: Wednesday, March 18, 2015 05:02 To: Tab Atkins Jr. Cc: es-discuss Subject: Re: String.prototype.trimRight/trimLeft Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec). I guess we just need to confirm it's good to go to ES7? Dmitry On Tue, Mar 17, 2015 at 12:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott leonarn...@gmail.com wrote: I believe opinion hasn't shifted since it was discussed [previously](https://esdiscuss.org/topic/standardizing-more-de-facto-functions) - in short, show me the cowpath. (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.) I use both lstrip() and rstrip() in Bikeshed (a Python project): https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=lstriptype=Code https://github.com/tabatkins/bikeshed/search?utf8=%E2%9C%93q=rstriptype=Code In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying. ~TJ ___ 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: Extensible destructuring proposal
On 21 July 2015 at 08:14, Samuel Hapák samuel.ha...@vacuumapps.com wrote: I have written proposal to allow extend standard behavior of object destructuring: https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md Main idea is, that currently object destructuring is useless for people who use Map or Immutable.Map (https://facebook.github.io/immutable-js/) as their main data structure. This would allow authors of libraries to create map like structures that would support destructuring. It extends the language in a similar way iterator does. The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. What do you think? People reading code will (rightfully) expect destructuring to be syntactic sugar for property access. I don't think it's worth breaking that equivalence. If you want user-defined patterns then they should be syntactically distinct from existing forms. Also, destructuring patterns are meant to match, and be the logical inverse of, literal syntax. Consequently, from my perspective at least, extensible destructuring would require first introducing extensible literal syntax in a symmetric manner. I think it would be unnecessarily surprising if for random patterns they didn't match up (worse, if you cannot even tell the meaning syntactically, but it depends on whatever object you happen to get). /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
On 21.7.2015, at 9:34, Andreas Rossberg rossb...@google.com wrote:
People reading code will (rightfully) expect destructuring to be syntactic
sugar for property access. I don't think it's worth breaking that
equivalence. If you want user-defined patterns then they should be
syntactically distinct from existing forms.
This is already not true for array destructuring. You can use it with any
iterables, not only with arrays.
`@@get` should be implemented only by “Map like” data structures. Destructuring
is usually used to extract deeply nested data from `Object`. I find hard to
believe that someone would deliberately use destructuring on `Map` or similar
structure to extract methods:
```
// very strange use of destructuring, don’t believe anyone is doing that
const {get, has, set} = myMap // instance of Map()
```
Much more common use case is that you have nested structure of “Map like”
structures and want to easily retrieve values.
Btw. this change is backward compatible, because it does not change behavior of
existing code. It just gives you ability to provide users with new
datastructures.
Also, destructuring patterns are meant to match, and be the logical inverse
of, literal syntax. Consequently, from my perspective at least, extensible
destructuring would require first introducing extensible literal syntax in a
symmetric manner. I think it would be unnecessarily surprising if for random
patterns they didn't match up (worse, if you cannot even tell the meaning
syntactically, but it depends on whatever object you happen to get).
As I have pointed out, this is not true for iterable destructuring.
```
[a, b, c] = someIterable; // someIterable does not have to be Array
```
This can be similarly surprising:
`someIterable[0] !== a // true`
Thanks,
Samuel
smime.p7s
Description: S/MIME cryptographic signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: await on synchronous functions
Just a few points to be careful about: Several people have been trying to assert in threads that await can be used to solve synchronous problems; but just like Dean stated, you need to turn the event loop which makes it problematic for things like https://github.com/whatwg/loader/issues/54 need to be sure we do not get confused. I want to make sure that any proposal does not squash the idea of Compositional Functions ( https://github.com/jhusain/compositional-functions/ ). For various reasons we do not use async/await with promises currently and use the same semantics as compositional promises due to resource management. On Mon, Jul 20, 2015 at 10:57 AM, Dean Landolt d...@deanlandolt.com wrote: On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Meaning putting a Promise in a chain of promises is a point of no return so I've never seen/heard/imagined a case where you have a promise and suddenly you refactor that to be synchronous. This is a great point, and I think makes a good argument against the refactoring use case. But there are other plenty of other interesting use cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics would allow you to write generic sync/async handlers, which comes up all over the place. This approach neatly cleans up some of the inconsistencies around handling sync throws vs. rejections vs. *zalgo* throws (usually promise-returning functions which throw before returning a promise). A try/catch around some `await` will handle all three cases the same, almost -- there's one small catch (w/ apologies for the bad pun)... IIUC the behavior of `Promise.resolve` alone are insufficient to get identical semantics between sync and async calls -- you'd need to spin the event loop before rethrowing a sync exception, akin to the behavior of bluebird's `Promise.try`. A minor detail, but punting on this would force users into wrapping every call with something like `Promise.try`, which seems like a shame. ISTM these `try` semantics, rather than `Promise.resolve`, are more natural as the foundation for `await`. The specific Promise gonna Promise was actually mentioning another thread about cancelability and the fact Promises are Promises and should just Promise :-) Sorry for the confusion On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller erig...@google.com wrote: Hi Andrea, what do you mean by Promise must Promise? I've never seen this phrase before. On Fri, Jul 17, 2015 at 11:35 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Think about a large program where you refactor a single async function to no longer be async did that ever happened in the history of logic? I am actually curious to understand a single valid case where that would be a solution to any problem. Apologies if I can't see your point but we've been talking about Promise must Promise so much this answer was absolutely unexpected. Thanks for any sort of clarification On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem tomvc...@gmail.com wrote: 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi andrea.giammar...@gmail.com: If I might, if there's one thing that has never particularly shone in JS, that is consistency. I see only two possibilities here: 1) it throws with non Promises 2) it Promisify anything that's not a Promise as if it was a `Promise.resolve(1)` ... but since there's too much magic in the second point, I'd rather stick with the first one. I would be highly in favor of (2). Think about a large program where you refactor a single async function to no longer be async. Then I see no reason why I should be forced to refactor all of its callers to remove the await keyword. Going from sync to async requires refactoring because you're introducing new potential interleaving hazards, but any code that is already prepared to work with async functions (or promises in general) should work equally fine on immediately resolved promises. regards, Tom Just my quick thoughts Best Regards On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith zenpars...@gmail.com wrote: I know the spec for this isn't finalized, but what is the current direction for the behaviour when await is used on a function that is not marked async and doesn't return a Promise? Should it run immediately or wait for the next turn of the event loop? More generally, the question is: what should await do for non-promises? await 1; Should it force a job to be queued? ___ 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: Extensible destructuring proposal
For maps you can just do
```js
const [[k1, v1], [k2, v2], ...rest] = map.entries();
```
There is no need to add more complexity to object destructuring (which should
only be used for objects and their string keys).
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Samuel
Hapák
Sent: Tuesday, July 21, 2015 08:29
To: es-discuss
Subject: Re: Extensible destructuring proposal
On 21.7.2015, at 9:34, Andreas Rossberg rossb...@google.com wrote:
People reading code will (rightfully) expect destructuring to be syntactic
sugar for property access. I don't think it's worth breaking that
equivalence. If you want user-defined patterns then they should be
syntactically distinct from existing forms.
This is already not true for array destructuring. You can use it with any
iterables, not only with arrays.
`@@get` should be implemented only by “Map like” data structures. Destructuring
is usually used to extract deeply nested data from `Object`. I find hard to
believe that someone would deliberately use destructuring on `Map` or similar
structure to extract methods:
```
// very strange use of destructuring, don’t believe anyone is doing that const
{get, has, set} = myMap // instance of Map() ```
Much more common use case is that you have nested structure of “Map like”
structures and want to easily retrieve values.
Btw. this change is backward compatible, because it does not change behavior of
existing code. It just gives you ability to provide users with new
datastructures.
Also, destructuring patterns are meant to match, and be the logical inverse
of, literal syntax. Consequently, from my perspective at least, extensible
destructuring would require first introducing extensible literal syntax in a
symmetric manner. I think it would be unnecessarily surprising if for random
patterns they didn't match up (worse, if you cannot even tell the meaning
syntactically, but it depends on whatever object you happen to get).
As I have pointed out, this is not true for iterable destructuring.
```
[a, b, c] = someIterable; // someIterable does not have to be Array ```
This can be similarly surprising:
`someIterable[0] !== a // true`
Thanks,
Samuel
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Extensible destructuring proposal
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?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
