Re: Weak References

it into the > language, so weak references are the best way to avoid this. And if I were > doing this in Java or C++, I would most definitely use weak > references/pointers for this use case. (This is out of the land of what > automatic garbage collection can handle at this point.) >

Re: Weak References

On Sun, Sep 6, 2015 at 8:04 PM, Isiah Meadows wrote: > My original email featured a use case, although I had to rewrite it to use > explicit garbage collection. I need a way to watch for when the object is > garbage collected. > > ```js > [...Somehow reformatted in

Re: Weak References

On Sun, Sep 6, 2015 at 10:32 AM, Isiah Meadows wrote: > That's actually the feature I need... > Hi Isiah and Thomas, what "That"? If you mean pre-mortem finalization, like Java's Object.finalize or the cited node callbacks (whose pre-mortem nature is made clear by

Re: Weak References

On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo wrote: > I think weak references are discussed before, and get postponed because it > can cause information leaks between realms. > http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says To plug this leak, a weak

Re: Weak References

On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows wrote: > I'm resurrecting this [1] because I have found a use case where I needed a > weak reference. Is there any chance this could get into the language? > I wrote the [1] strawman and continue to be positive on the idea.

Re: Weak References

On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows wrote: [...] Thankfully, I'm using Node.js, so `weak` [2] is an option (the only option, > really). But I would definitely appreciate if it was available in JS > proper, across engines. V8, SpiderMonkey, and JSC all have weak

Re: Exponentiation operator precedence

, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). On Wed, Aug 26, 2015 at 9:00 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller erig...@google.com wrote: When the costs were minor, it was ok that the benefits were minor

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 2:55 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first

Re: Assignment of global variables deleted by their RHS in strict mode

On Wed, Aug 26, 2015 at 2:55 PM, Kevin Gibbons ke...@shapesecurity.com wrote: See the following test262 test: https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js (and related tests with update / compound assignment). In short, it is possible to

Re: Exponentiation operator precedence

I completely agree. My When the costs were minor refers to when we were not yet aware of the conflict. On Wed, Aug 26, 2015 at 12:19 AM, Claude Pache claude.pa...@gmail.com wrote: Le 26 août 2015 à 00:43, Mark S. Miller erig...@google.com a écrit : When the costs were minor, it was ok

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 6:19 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my objection is. The yield counter-example is interesting, but yield is an identifier not an operator symbol, and so does

Re: Exponentiation operator precedence

It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com wrote: It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah

Re: Exponentiation operator precedence

Sorry. I just has another look at your proposed grammar and you are correct. On Tue, Aug 25, 2015 at 10:54 AM, Claude Pache claude.pa...@gmail.com wrote: Le 25 août 2015 à 19:25, Mark S. Miller erig...@google.com a écrit : It also does not work. x ** y ** z, if we allow it at all, must

Re: Exponentiation operator precedence

I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime

Re: Exponentiation operator precedence

It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com wrote: I like this. It works very well. On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote: I think the following grammar could work. Replace

Re: Exponentiation operator precedence

When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: Why do we need ** ? What great benefit does it provide? If nothing compelling, then this proposal has lost consensus. On Tue, Aug 25, 2015 at 3:30 PM, Claude Pache claude.pa...@gmail.com

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 3:28 PM, Mark S. Miller erig...@google.com wrote: [+google-caja-discuss] Cool. I will fix the debug.js adaptor a) to fix the bug Boris reported, b) to map the FF nested format to the v8 nested format, and c) to preserve this information from the v8 API so

Re: await on synchronous functions

On Sun, Jul 19, 2015 at 10:16 AM, Bergi a.d.be...@web.de wrote: Mark S. Miller wrote: We've talked about allowing await at the top level of modules, I think so that the await continuation could proceed after the synchronous part of the load. I am unclear on the details and cannot

Re: Generalize do-expressions to statements in general?

2015 at 17:29, Mark S. Miller erig...@google.com wrote: When simply generating simple JS code from something else, this restriction is a perpetual but minor annoyance. Indeed, one motivation for do-expressions is better support for compilers targeting JS. And for some of those, not being able

Re: await on synchronous functions

I would expect any implementation to do #2 since that's what the draft spec says. On Fri, Jul 17, 2015 at 12:40 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: Yes, I am asking about case #2. Thanks for clarifying Chris. For what it's worth, Traceur allows this now. On Fri, Jul 17, 2015

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 3:06 PM, Alexander Jones a...@weej.com wrote: Changing a function from returning a PromiseT to returning a T is just the same as changing it to return any other type. This sounds like the old monad vs promise debate. EcmaScript promises have already decided against the

Re: await on synchronous functions

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

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman benja...@cs.stanford.edu wrote: If we stick with the rule that await is only regarded as a keyword if it appears in the body of an async function, then await x without async is simply a syntax error, and we can avoid having to answer this question!

Re: await on synchronous functions

Wait for the next turn/job or the event loop. On Fri, Jul 17, 2015 at 10:09 AM, Mark Volkmann r.mark.volkm...@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

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 10:33 AM, 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

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:57 PM, Ben Newman benja...@cs.stanford.edu wrote: Yep, all current implementations that I know of (Traceur, Babel/Regenerator, various other generator-based approaches) do what you want, because Promise.resolve(fn()).then(result = ...) always runs the callback a

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 10:41 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:44 PM, Ben Newman benja...@cs.stanford.edu wrote: Having addressed (1) earlier, perhaps by mistake, my thought on (2) is that you probably want await f() to work the same way if f() just happens to return a Promise, as when f is actually async, but there is no way to

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:50 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: Going back to my original question, suppose I write this: for (let fn of myFunctions) { let result = await fn(); // Do something with result. } If all the functions happen to be synchronous and take a

Re: Generalize do-expressions to statements in general?

I echo this. E is a dynamic language with many similarities with JS, including a similarly C-like syntax. In E I use everything-is-a-pattern-or-expression all the time. When I first moved to JS I missed it. Now that I am used to the JS statements-are-not-expressions restrictions, I no longer do,

Re: Generalize do-expressions to statements in general?

. Retrofitting without breaking things takes much longer than invention ;) /Andreas On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote: Interesting. Got me thinking. Here's an alternate proposal I'll call do expressions without the 'do'. At https://people.mozilla.org/~jorendorff

Re: Generalize do-expressions to statements in general?

On Tue, Jul 14, 2015 at 10:59 AM, Andreas Rossberg rossb...@google.com wrote: On 14 July 2015 at 16:48, Mark S. Miller erig...@google.com wrote: On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg rossb...@google.com wrote: I don't see why you need parens at all, see my previous post. But I

Re: Generalize do-expressions to statements in general?

Interesting. Got me thinking. Here's an alternate proposal I'll call do expressions without the 'do'. At https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement we have the syntax of the expression statement. Ignoring sloppy let nonsense, this says that an expression

Re: RegExp.escape()

Safety over readability please. If there is a single fully escaped form that is safe to use in all the expected contexts, let's choose that. The results of RegExp.escape are not very readable anyway, and rarely read. So compromising safety for some contexts in exchange for incremental readability

Re: Awaiting thenables

Y -- Cheers, MarkM On Jun 26, 2015 2:07 PM, Jordan Harband ljh...@gmail.com wrote: so, in other words, `await thenable` would wrap the thenable in `Promise.resolve`, which would ensure it fires on the next tick? On Fri, Jun 26, 2015 at 12:36 PM, Mark S. Miller erig...@google.com wrote

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 2:17 PM, Brendan Eich bren...@mozilla.org wrote: Hrm, the meeting notes don't quite capture it ( https://github.com/tc39/tc39-notes/blob/bf5190257d22d1c700e203b28edc8d85ee3aadcc/es6/2015-05/may-27.md is one view; my fault for not editing after), but we have discussed

Re: function.sent beta equivalence?

Jason Orendorff wrote: Quick question about function.sent: As of ES6, there's this parallel between functions and generators: // how to wrap a function // f2 is equivalent to f, if f doesn't use `this`. function f(...) { ... } function f2(...args) { return

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 3:17 PM, Mark S. Miller erig...@google.com wrote: Jason Orendorff wrote: Quick question about function.sent: As of ES6, there's this parallel between functions and generators: // how to wrap a function // f2 is equivalent to f, if f doesn't use

Re: function.sent beta equivalence?

I only sent three messages in this thread before this one. The first was completely blank, which was only a premature hitting of send, so only two real messages. On Wed, Jun 24, 2015 at 4:42 PM, Brendan Eich bren...@mozilla.org wrote: Jason Orendorff wrote: What does wrap look like? It seems

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

would suggest for JS that this list include the things required for confining a piece of JS code running within a larger environment, like a web page to keep it from doing all the things the web page can do. Hi Bill, regarding the list of bullets On Fri, Jun 19, 2015 at 11:12 AM, Mark S. Miller

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Someone just brought https://news.ycombinator.com/item?id=9742823 to my attention. It says: I like the author’s remarks and philosophy about keeping JavaScript small, but I thought the opening was remarkably uncharitable. The specific person and the specific feature are quite irrelevant to the

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell slightly...@google.com wrote: I do not share Mark's view. Contra his sentiment, I was using the small version of JS for many years and noted that most non-trivial uses required finding or building a library. That choice of library (which exist to

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

use strict was only a breaking change regarding ES3 code that coincidentally happened to use exactly this literal string as a do-nothing expression statement in exactly this position. In all of the web, we have not run across a single incident of this happening accidentally. For the record, not

The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson get...@gmail.com wrote: I'd like to ask if there's anyone on TC39 that would be willing to champion a proposal to add the let-block (let-statement) syntax? I am not. Further, if anyone were, I would work to kill it. Here's why. The Algol,

Re: Template site objects and WeakMap

On Wed, Jun 17, 2015 at 11:19 AM, Yusuke SUZUKI utatane@gmail.com wrote: It turns out the spec is fine https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set step 5 says If Type

Re: Template site objects and WeakMap

page with this — just FYI On Jun 17, 2015, at 2:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/17/15 2:35 PM, Mark S. Miller wrote: What do other browsers currently do? Firefox: var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true); TypeError: r is not a non-null

Re: Template site objects and WeakMap

On Wed, Jun 17, 2015 at 9:31 AM, Yusuke SUZUKI utatane@gmail.com wrote: On Thu, Jun 18, 2015 at 1:18 AM, Mark S. Miller erig...@google.com wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix

Re: Re: Template site objects and WeakMap

The idea that (a shared Weak interning table of immutable-objects-with-identity + WeakMaps makes gc observable) is not new. The idea that (the shared interning tables of immutable-objects-with-identity must therefore be strong) is not new. What was new to me is the idea that Interning of a

Re: Template site objects and WeakMap

let's not. On Wed, Jun 17, 2015 at 1:51 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 17, 2015, at 9:18 AM, Mark S. Miller wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix

Re: Template site objects and WeakMap

[+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Template site objects and WeakMap

Hi Yusuke, I am not sure I understood your message. Could you show some example code that would observe the observable difference you have in mind? On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI utatane@gmail.com wrote: Hi forks, In ES6 spec, template site objects are strongly

Re: Template site objects and WeakMap

the hashing occurs), there’s no way to store these callsites in a WeakMap, and they are never collected. If WeakSets were iterable, this could be solved pretty easily, but these are the tools we’ve got :( On Jun 16, 2015, at 10:31 PM, Mark S. Miller erig...@google.com wrote: Hi Yusuke, I am

Re: Template site objects and WeakMap

(which aren’t available at parse-time when the hashing occurs), there’s no way to store these callsites in a WeakMap, and they are never collected. If WeakSets were iterable, this could be solved pretty easily, but these are the tools we’ve got :( On Jun 16, 2015, at 10:31 PM, Mark S. Miller

Re: RegExp.escape()

Perfection? function re(first, ...args) { let flags = first; function tag(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i numSubs; i++) { parts.push(template.raw[i]); const subst = subs[i] instanceof RegExp ?

Re: RegExp.escape()

The point of this last variant is that data gets escaped but RegExp objects do not -- allowing you to compose RegExps: re`${re1}|${re2}*|${data}` But this requires one more adjustment: function re(first, ...args) { let flags = first; function tag(template, ...subs) { const

Re: RegExp.escape()

Good idea bug infinite recursion bug. Fixed: function re(first, ...args) { let flags = first; function tag(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i numSubs; i++) { parts.push(template.raw[i]);

Re: RegExp.escape()

On Sat, Jun 13, 2015 at 11:39 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: On Sat, Jun 13, 2015 at 9:07 PM, Mark S. Miller erig...@google.com wrote: On Sat, Jun 13, 2015 at 9:17 AM, Domenic Denicola d...@domenic.me wrote: All of these should be building on top of RegExp.escape :P

Re: RegExp.escape()

with an error. But what if the strings happen to be mutually valid but with conflicting meaning between these subclasses? *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark S. Miller *Sent:* Saturday, June 13, 2015 02:39 *To:* C. Scott Ananian *Cc:* Benjamin

Re: RegExp.escape()

Nice! Inspired // Based on // https://github.com/benjamingr/RexExp.escape/blob/master/polyfill.js function re(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i numSubs; i++) { parts.push(template.raw[i]);

Re: Ideas on type hinting and named parameters

On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott l...@webconnex.com wrote: [...] It currently uses `=` to define properties. And there is some debate whether or not properties should be initialized in the constructor or be on the prototype. There is no debate about whether per-instance state (of

Re: PerformPromiseAll

It would help to have a concrete motivating example where the Promise subclass were usefully distinct from the Promise subclass' species. On Tue, Jun 9, 2015 at 7:30 AM, C. Scott Ananian ecmascr...@cscott.net wrote: `Promise.resolve` doesn't use the species pattern any more:

Re: PerformPromiseAll

On Tue, Jun 9, 2015 at 7:58 AM, C. Scott Ananian ecmascr...@cscott.net wrote: Mark: I outlined two of these use cases in https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 One is `WeakPromise` which is a promise holding a weak reference to its resolved value.

Re: When the only tool you have is subclassing, all extensions look like....

make work with a Promise subclass? Funny enough, I replied before I saw this. The use case I can't make work using only subclassing as an extension mechanism is promise pipelining. --scott On Tue, Jun 9, 2015 at 12:13 PM, Mark S. Miller erig...@google.com wrote: My larger theme here

Re: PerformPromiseAll

I know I'm being picky here, but if timeout-ness is not intended to propagate, which seems sensible, then why would I ever want to invent a TimeoutPromise subclass rather than using a combinator like delay or race on a plain Promise? ___ es-discuss

Re: When the only tool you have is subclassing, all extensions look like....

On Tue, Jun 9, 2015 at 9:13 AM, Mark S. Miller erig...@google.com wrote: My larger theme here is that I think promise subclassing is way overrated. OO programmers tend to treat subclassing according to the everything is a hammer rule. Promises do need an extension point, such as the old

When the only tool you have is subclassing, all extensions look like....

email.) On Tue, Jun 9, 2015 at 9:00 AM, Mark S. Miller erig...@google.com wrote: I know I'm being picky here, but if timeout-ness is not intended to propagate, which seems sensible, then why would I ever want to invent a TimeoutPromise subclass rather than using a combinator like delay or race

Re: Ideas on type hinting and named parameters

/assignment through the prototype getter anyway. JS4lf ... you hit an already opened door about strict descriptors, already proposed years ago ;-) https://github.com/WebReflection/define-strict-properties#define-strict-properties Best Regards On Tue, Jun 9, 2015 at 4:44 PM, Mark S

Re: PerformPromiseAll

On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian ecmascr...@cscott.net wrote: Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a `TimeoutPromise` subclass. But this is really a language-design question. You might as well ask why we have `WeakMap()` as a constructor

Re: When the only tool you have is subclassing, all extensions look like....

(); // first argument is destination of the operation rpcCall(this.handle, ...args).then( v = res(v), e = rej(v) ); } } ``` --scott ​ On Tue, Jun 9, 2015 at 12:56 PM, Mark S. Miller erig...@google.com wrote: On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian ecmascr...@cscott.net wrote

Re: Fixing `Promise.resolve()`

Hi Scott, If the change is as simple as it appears, it seems it will go into ES6 itself! Thanks for pushing this forward. On Tue, Jun 2, 2015 at 1:25 PM, C. Scott Ananian ecmascr...@cscott.net wrote: Thanks! It looks like core-js has already patched in the new spec:

Re: let function

Yes. I proposed it and plan to do so again. Likewise with const classes. In both cases, it imposes additional tamper-proofing restrictions along the lines of the StrongScript proposal in order to support writing defensively consistent abstractions. On Tue, May 19, 2015 at 3:02 PM, Kevin Smith

Re: *.empty Idea

not extend to considering the mutability of the contents of the collections. I welcome proposals that would make sense for JavaScript. On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian ecmascr...@cscott.net wrote: On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller erig...@google.com wrote

Re: *.empty Idea

. On Thu, Apr 30, 2015 at 11:18 AM, Mark S. Miller erig...@google.com wrote: Hi Scott, this would only be confusing. Object.tamperProof is built on and implies Object.freeze. It is like Object.freeze except that it replaces (some :( ) data properties with accessors in order to work around

Re: *.empty Idea

, Mark S. Miller erig...@google.com wrote: This must *not* be hung off of Object.freeze. Object.freeze is about tamper proofing an object's API, not about making its internal state immutable. I regret the term freeze for this purpose as it repeatedly suggests this confusion. OTOH, because

Re: *.empty Idea

]] slot to protect it. --scott On Thu, Apr 30, 2015 at 2:42 PM, C. Scott Ananian ecmascr...@cscott.net wrote: On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller erig...@google.com wrote: It would also not be compatible with ES6 code. SES will be freezing Map, Set, WeakMap, and WeakSet

Re: *.empty Idea

On Thu, Apr 30, 2015 at 12:46 PM, C. Scott Ananian ecmascr...@cscott.net wrote: I like the idea of snapshot methods, but they can be implemented in user code using subclasses in ES6. I'm particularly interested in the lock down in place mechanism because it *cannot* be implemented in user

Re: *.empty Idea

It doesn't matter. Others will do the same thing in ES6 and then break under your proposal in ES7. On Thu, Apr 30, 2015 at 11:42 AM, C. Scott Ananian ecmascr...@cscott.net wrote: On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller erig...@google.com wrote: It would also not be compatible

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 11:12 AM, C. Scott Ananian ecmascr...@cscott.net wrote: On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller erig...@google.com wrote: Hi Scott, I think your approach is on the right track. How about the following? Anyone see a way to attack it? const goodPromises

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 12:40 PM, C. Scott Ananian ecmascr...@cscott.net wrote: On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com

Re: Subclassing ES6 objects with ES5 syntax.

I do indeed need to expose DefensivePromise under the global name Promise, replacing the builtin. Other than itself being frozen and making frozen promises, it should in all other ways conform exactly to the promise spec while still guaranteeing this invariant. ``` constructor(x) {

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian ecmascr...@cscott.net wrote: On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller erig...@google.com wrote: The invariant I am interested in: In a realm where we (the trusted defender who runs first) make Promise defensive as follows * Freeze

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian ecmascr...@cscott.net wrote: [...] Mark, after you've slept on this and assuming you haven't changed your mind, would you be willing to be the TC39 champion? I'm not a participant in that process. Yes. -- Cheers, --MarkM

Re: forward-incompatible Function.prototype.toString requirement

On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev kan...@gmail.com wrote: I did some research on this just last year — http://perfectionkills.com/state-of-function-decompilation-in-javascript/ (and originally back in 2009, when things were much wilder,

Re: Putting `global` reference in specs

On Fri, Apr 17, 2015 at 8:33 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: it's a no-go under CSP so it's as bad as `Function('return this')()` Precisely. Which raises an interesting point. Does anyone know of a *precise* statement of the actual threat model that CSP's no eval is

Re: Putting `global` reference in specs

, 2015 at 8:53 AM To: Glen Huang curvedm...@gmail.com Cc: Mark S. Miller erig...@google.com, es-discuss@mozilla.org es-discuss@mozilla.org Subject: Re: Putting `global` reference in specs This is one of several cases where, post ES6, we can provide a std module import that provides a built

Re: Putting `global` reference in specs

(1,eval)('use strict; this') On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: there's actually no way, officially, to reference what ES2015 call *the global object*, just pointless fragmentation between engines. On Fri, Apr 17, 2015 at 4:19 PM, Anne

Re: Putting `global` reference in specs

, 2015 11:53 AM *To:* Glen Huang *Cc:* Mark S. Miller; es-discuss@mozilla.org *Subject:* Re: Putting `global` reference in specs This is one of several cases where, post ES6, we can provide a std module import that provides a built-in that carries authority. Another example is the constructor

Re: Putting `global` reference in specs

, Mark S. Miller erig...@google.com wrote: On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: also `eval` can be in-scope redefined as much as global, window, or self, so no, that's actually not a solution. Btw, I wasn't asking for a workaround, I

Re: Putting `global` reference in specs

:27, Mark S. Miller erig...@google.com wrote: (1,eval)('use strict; this') Is the 'use strict' relevant here? Seems overkill. /Andreas On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: there's actually no way, officially, to reference what ES2015

Re: Putting `global` reference in specs

) On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: it's a no-go under CSP so it's as bad as `Function('return this')()` On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/17/15 11:27 AM, Mark S. Miller wrote: (1,eval)('use

Re: forward-incompatible Function.prototype.toString requirement

On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller erig...@google.com wrote: On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg rossb...@google.com wrote: On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com wrote: The part that sticks out to me is... toString on functions

Re: Nailing object property order

Developer productivity hypothetical minor performance gains. +1 to all steps to make the specified behavior more deterministic, including this one. On Thu, Apr 16, 2015 at 10:07 AM, liorean lior...@gmail.com wrote: I'm very much opposed to locking this down for general objects because it

Re: forward-incompatible Function.prototype.toString requirement

, Mark S. Miller erig...@google.com wrote: On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg rossb...@google.com wrote: On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com wrote: The part that sticks out to me is... toString on functions currently throws a syntax error when

Re: forward-incompatible Function.prototype.toString requirement

/source/browse/trunk/src/com/google/caja/ses/startSES.js#901 ). On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller erig...@google.com wrote: On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg rossb...@google.com wrote: On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com wrote

Re: Array comprehensions with Spread operator

Dave Herman did an excellent presentation at one of the TC39 meetings that convinced us all to drop comprehension syntax from ES6. I remember it surprised us all including, earlier Dave, which led to his presentation. Anyone have a link? The arguments that I remember as most significant are a)

Re: Array comprehensions with Spread operator

On Wed, Apr 15, 2015 at 1:11 PM, monolithed monolit...@gmail.com wrote: @Mark S. Miller, Dave Herman did an excellent presentation at one of the TC39 meetings that convinced us all to drop comprehension syntax from ES6. I remember it surprised us all including, earlier Dave, which led

Re: Number.prototype not being an instance breaks the web, too

On Mon, Apr 13, 2015 at 12:53 PM, Jordan Harband ljh...@gmail.com wrote: Please note that the `@@toStringTag` changes mean that we do need to always have a Number.prototype method that throws when the value does not have a [[NumberData]] internal slot - I'm using `Number#toString` for that

Re: Number.prototype not being an instance breaks the web, too

fixed Object.prototype.toString.call(null) incompat with jQuery.) Could someone please reply-all to this thread cc'ing Piotr Zalewa and Oskar Krawczyk? Thanks. On Mon, Apr 13, 2015 at 8:26 AM, Mark S. Miller erig...@google.com wrote: I agree. With Number.prototype joining Array.prototype

Re: Number.prototype not being an instance breaks the web, too

I agree. With Number.prototype joining Array.prototype and Function .prototype on the dark side, we should ask which others should too. When it was only Function.prototype and Array.prototype, principle of least surprise (POLS) had us keep the list as small as possible -- until we had precisely

Re: Number.prototype not being an instance breaks the web, too

On Mon, Apr 13, 2015 at 8:37 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 13, 2015, at 8:26 AM, Mark S. Miller wrote: ... Allen, process-wise, is this too late for ES6? If there's any way this fix can go in ES6, it should. Otherwise, it should become the first member

<    1   2   3   4   5   6   7   8   9   10   >