Re: RegExp.escape
I made an initial repo https://github.com/benjamingr/RexExp.escape/blob/master/README.md I've added a reference to that gist - I'll start poking around and have scheduled to meet with some local people interested in helping next week. I'll keep you updated. On Fri, Jun 12, 2015 at 9:57 PM, Juriy Zaytsev kan...@gmail.com wrote: I made this gist back in the days — https://gist.github.com/kangax/9698100 — and I believe Rick was going to bring it up at one of the meetings. I don't have time to set up repo and work with TC39 member so if you can continue carrying that torch, that would be awesome! -- kangax On Fri, Jun 12, 2015 at 2:52 PM, Benjamin Gruenaum benjami...@gmail.com wrote: You know what? Why not. I'm going to try to champion this. I talked to Domenic and he said he's willing to help me with this which is a big help (this would be my first time). I'll open a GitHub repo and see what I can come up with. ___ 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: `new Object` vs `Object` difference
That's good to know and it's good to know I'm not the first one to spot this. While we're visiting the spec on that: Why is it specified that When called as a constructor it creates a new ordinary object. When Object is called as a function rather than as a constructor, it performs a type conversion. - wouldn't it make more sense to remove that or specify behaves the same way? Where is it actually explained what Object does when called as a constructor? The difference - at least in the phrasing of Object vs Array seems to be just as present in the latest spec draft from what I can tell. On Sat, Jun 13, 2015 at 12:38 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: ES6 eliminates the (possible) special treatment of host objects passed as the argument to the Object constructor. As far as anybody seems to know, no implementation had ever made use of that allowance. The ES6 spec. also unifies the [[Call]] and [[Constructor]] behavior of Object into a single algorithm http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value ES6 unifies all [[Call]] and [[Construct]] algorithms for built-in constructors in this same manner. Allen On Jun 12, 2015, at 1:19 PM, Benjamin Gruenaum wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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: `new Object` vs `Object` difference
Thanks, Array and Function (as well as RegExp) actually directly specify that calling them with and without new produces equivalent results where `Object` doesn't and actually has a hole (in what it _may_ do to host objects). It's just baffling that `Object` is defined so differently. I wonder if there are old browsers that differ on this, or there is a bigger reason for this behaviour. On Sat, Jun 13, 2015 at 12:05 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I think historically `Array`, `Function`, and `Object` can be used with or without `new` and the result is exactly the same ... since, about, ever. Agreed if that's actually indeed the case, we could have just one definition for those 3 constructors (not just Object) Regards On Fri, Jun 12, 2015 at 10:19 PM, Benjamin Gruenaum benjami...@gmail.com wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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
`new Object` vs `Object` difference
Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
You know what? Why not. I'm going to try to champion this. I talked to Domenic and he said he's willing to help me with this which is a big help (this would be my first time). I'll open a GitHub repo and see what I can come up with. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
Reviving this, a year passed and I think we still want this. We have even more validation than we had a year ago (added by libraries like lodash) and this is still useful. What would be the required steps in order to push this forward to the ES2016 spec? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
If you want a special Promise (subclass or extended), you should not use async function since it casts the return value to a standard Promise Right, there was a proposal that let you override how await works ( https://github.com/jhusain/compositional-functions) but I don't think it's currently actively persued (Jafar, feel free to correct me here). If you want to return a promise and attach callbacks to it (not returning promise that spawns by then), you should not use async This is also correct. it’s quite hard to determines if one method is actual async (with Promise) or sync (immediately return values), so I may preferr to mark all async function async for better read experience I don't think the distinction is correct. For the consumer - it is irrelevant if a function is async or just returns a promise. If you're writing an API and your function _sometimes_ return promises it is best to make them always return promises - more generally if a function is sometimes asynchronous (with callbacks too) it should always be asynchronous. Never write return await xxx;, it seems useless either xxx is a promise or not Yes, unless of course you're also doing other things inside the function. Anyway this is not an issue about spec itself, it’s more like an open discussion, thanks for reply :) Correct - I'm in no position to tell you what you can and cannot do but in the future I think it is best to ask these questions in Stack Overflow, IRC and on discussion groups. If you have issues about style, usage or anything else that is not the spec it is best to keep them off esdiscuss which is quite a noisy list anyway :) Feel free to send me an email (rather than the whole list) if you have other issues with `async` that are not spec related. Cheers. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
A function needs to be defined `async` if you intend to possibly use the
await keyword inside it.
If a function is returning Promise, it MUST be async If a function
depends on an async function, it **MUST be async A further question could
be, if one function only contains some simple then calls to promise, should
it become an async function and use await in all possible cases to
eliminate then calls?
No, it's possible to have legitimate use cases where this is not the case,
for example:
```js
async function foo() { ...} // queries an API
async function bar() { ... } // queries an API
function fooBar() {
return Promise.all([foo(), bar()]);
}
```
It's a contrived simplified example but the point is you might have
functions that work on promises that should not themselves be `async`.
For example, in your updateUser function, you can remove `async` and
`await` and get the same value (as you observed in growUp1).
To clarify, there is no _semantic_ distinction in your examples between an
async function and a regular function that returns a promise - it's just
syntax sugar - just like generators and regular functions that return
iterables.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
Am I missing something obvious in `super((resolve, reject) = this)` ? First of all, it makes perfect sense for `this` not work work before super has been called - and it has not been called yet. I think that the crux is that the promise constructor runs _synchronously_ so when you pass it `this` it has not finished running yet. Of course, the workaround as domenic has pointed is to extract `resolve` and `reject` from the `super` call since it is synchronous. (also I'm assuming you're not really mapping `(resolve, reject)` to `this`? `this` is an object and the promise constructor ignores return values anyway, you might as well pass a no-op in.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Actual WeakSet Use Cases
So umm... not to be annoying but I've been digging through esdiscuss and various blog posts online. I couldn't really find any use case for WeakSet (plenty of threads about naming things :P). Most material about it online fails to distinguish it from what one would use a regular Set for. All the use cases I know for `WeakSet` for tagging objects aren't really relevant in JS (for example - in shared memory threading scenarios). Can someone show me a convincing actual use case for WeakSet that can't better be solved without it? Thanks, and sorry, Benjamin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Actual WeakSet Use Cases
Thanks Domenic, Elaborating on your example with more details. Let's say you need to make sure at a certain point that an object has not been tinkered with by user code (for security reasons). You can't check the prototype or a symbol since those can be faked and you can't keep a regular `Set` because that would prevent any `Foo` object from ever being garbage collected. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to add EventEmitter to core [ES7]
Note that when/if observables land we get an event-emitter mechanism in the language anyway. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Consider javascript already support for default parameters, so maybe we can use the default parameter to specify the strong type.
What about non-default parameters? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
