getOwnPropertyDescriptor side effects
Is there any position on whether getOwnPropertyDescriptor should not have side-effects? I ask because some v8 getOwnPropertyDescriptor *do* have side effects (for example, Object.getOwnPropertyDescriptor(new Error, “stack”) will call Error.prepareStackTrace (it used to not)). Currently I treat getOwnPropertyDescriptor as a “safe” way to observe an object — (unlike say calling each member on an object which could set off getters). -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
with + let
Just curious how the following code should behave: ```javascript var a = { x: 10 }; with (a) { let x = 20; } console.log(a.x); ``` a.x is still 10 in a repl I tried. However, if it was var x in the with x would be 20. Is let not affecting the with expected behavior? -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Exporting Symbols
Not sure if it isn’t the case, but it seems the only way to export symbols right now is: ```js export default { [Symbol(“something”)]: blah } ``` It would be nice if “symbol literals” could somehow be supported. In particular, I can imagine this sort of thing becoming common: export { “5.4” as Symbol(“version”) } Or, even better (but harder since its now more expression): import VersionSymbol from “symbols" export { “5.4” as VersionSymbol } I’m currently writing an API where there are expected methods stored in symbols, but this forces exporting one default object instead of being able to lay them out individual. Thanks, Francisco -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exporting Symbols
There are special features we want to expose if a module defines a certain key. However, we’d like to not rely on certain names just because there’s some chance they came up with it themselves. If it was a symbol that we gave them access to, it would be impossible for this to be the case, they would have had to grab the symbol from us: var SpecialSymbol = require(“our-symbols”).SpecialSymbol; export { whatever as SpecialSymbol } The difficulty I’m having right now is being torn by two competing “best practices”: on the one hand, you can’t do what I did above for the runtime reasons, on the other hand you CAN actually pull it off using the export default strategy, and in that situation it technically is safer for us to use our special symbol instead of relying on a string match. On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth <loganfsm...@gmail.com> wrote: > The main issue is that modules are statically analysable and > imports/exports are processed before the module executes, and the behavior > of a symbol is by definition a runtime thing. Until the code executes, > there would be no symbol object, and there would be no way to know what > thing was being imported imported / exported. > > The primary benefit of symbols is that they are unique, and cannot collide > unless you have a reference to them. Module exports have full control over > their names and don't have the same collision issues that objects and > classes generally do. What is the benefit you are hoping to get from > exposing these values on symbols instead of string keys? > > > > On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky <tolma...@gmail.com> > wrote: > >> Not sure if it isn’t the case, but it seems the only way to export >> symbols right now is: >> >> ```js >> export default { [Symbol(“something”)]: blah } >> ``` >> >> It would be nice if “symbol literals” could somehow be supported. In >> particular, I can imagine this sort of thing becoming common: >> >> export { “5.4” as Symbol(“version”) } >> >> Or, even better (but harder since its now more expression): >> >> import VersionSymbol from “symbols" >> export { “5.4” as VersionSymbol } >> >> I’m currently writing an API where there are expected methods stored in >> symbols, but this forces exporting one default object instead of being able >> to lay them out individual. >> >> Thanks, >> >> Francisco >> >> -- >> Francisco Tolmasky >> www.tolmasky.com >> tolma...@gmail.com >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Awaiting thenables
Apologies, I’m aware the last example didn’t make sense. What I meant was more along the lines of the following: setImmediateOrOtherNextRunLoopMethod(function() { console.log(6) }) console.log(await { then: function(x) { x(5) } }) In other words, would the “then” fire on the same run loop (since it isnt a fancy Promise), or still have the underlying await engine (step function) make sure it takes place on the next iteration (and in this case thus possibly make it show up after the 6 instead of beefore). On Fri, Jun 26, 2015 at 11:40 AM, Francisco Tolmasky tolma...@gmail.com wrote: Out of curiosity, in ES7, would the following code: console.log(await { then: function(x) { x(5) } }) console.log(6) Print out 5 then 6, or still 6 then 5? In other words, is the asynchronousness gauranteed by the await, or by the underlying Promise implementation? -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Awaiting thenables
Out of curiosity, in ES7, would the following code: console.log(await { then: function(x) { x(5) } }) console.log(6) Print out 5 then 6, or still 6 then 5? In other words, is the asynchronousness gauranteed by the await, or by the underlying Promise implementation? -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Subclassing Function
In the existing implementations I’ve tried, it appears I can’t do this: class SuperFunction extends Function { } (also tried with constructor(str) { super(str) }) It “works”, but the resulting new SuperFunction(“return 5”) is just a Function, not a SuperFunction. Is Function meants to be an exception to the subclassing built-ins, or should it also work? Thanks, Francisco -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
non-strict direct eval in top level scope
Apologies as I believe this has been discussed before ( https://esdiscuss.org/topic/block-scope-direct-non-strict-eval ), but just trying to get some clarification as to the current state of things, and have not been able to find this information (in a format I can understand). Namely, I’m curious whether eval(“let x = 5”) adds x to the current scope, if not in strict mode, at the “top level” (i.e. not in a function) and called directly. My impression was that with let it should not be adding anything to the current scope, but my tests in Mozilla Firefox (in the console) seem to suggest they do: eval(“let x = 5”) undefined x 5 In fact, even in functions: (function() { eval(let xyz = 555); console.log(xyz) })() 555 In if statements, it seems to be tacked onto the global scope: if (true) { eval(“let x = 5”) } x 5 If these are just bugs that’s fine, but if not, could someone tell me the expected behavior? Is it always supposed to act as if its creating a new scope for the blocks, or always *except* for top level evals? Or never? Thanks, Francisco -- Francisco Tolmasky www.tolmasky.com tolma...@gmail.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss