Re: possible excessive proxy invariants for Object.keys/etc??

I am looking forward to proxies in JavaScript, and had a thought on the issues below. You could extend the the direct proxy approach for this. When the Proxy receives getOwnPropertyNames, it 1) notifies the handler that property names are being requested 2) the handler adds/removes any

Re: Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

I started to respond to Allan's message, but I'll combine them to here. Note the additional proposal in the middle of the message. On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote: 2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com I have a couple virtual object use

Re: Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

On Wed, Nov 28, 2012 at 1:09 PM, Tom Van Cutsem tomvc...@gmail.com wrote: 2012/11/26 Dean Tribble dtrib...@gmail.com ... I agree. My usual expectation for proxies is to support remote and persistent objects. While supporting other scenarios is great, usually that's incidental

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I've built multiple large systems using promises. A fundamental distinction that must be clear to the client of a function is whether the function goes async: does it return a result that can be used synchronously or will the result only be available in a later turn. The .Net async libraries

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Hmm. I agree that the example code isn't relevant to JavaScript. For background, the last time issues this came up for me was in the context of a language keyword (which had other interesting but unrelated trade offs), where it really did impose that interaction (call sites had to declare that the

Re: Precedence of yield operator

To: Dean Tribble trib...@e-dean.com I’m not on the mailing list. Feel free to forward to it. ** ** In C# we have separate keywords too, and indeed the precedence differs as described below. For “yield return” (our yield) the lower precendence falls out naturally since it engenders a statement

Cancellation architectural observations

Another thread here brought up the challenge of supporting cancellation in an async environment. I spent some time on that particular challenge a few years ago, and it turned out to be bigger and more interesting than it appeared on the surface. In the another thread, Ron Buckton pointed at the

Re: Exponentiation operator precedence

Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and there are as many uses of Math.sin as there are

Re: Promises as Cancelation Tokens

>From experience, I'm very much in favor of the cancellation token. Though promises provide a good inspiration for cancellation, they don't quite fit the problem directly. The approach has been explored, though the details are not published. I implemented cancellation for the Midori system.

Re: non-self referencial cyclical promises?

I agree that the standard shoudl require a deterministic error, and I thought it did. In https://tc39.github.io/ecma262/#sec-promise-resolve-functions: 6. If SameValue(resolution, promise) is true, then > a.Let selfResolutionError be a newly created TypeError object. > b.Return

Weak Reference proposal

I have posted a stage 1 proposal for weak references in ES7 for your perusal and feedback. https://github.com/tc39/proposal-weakrefs.git Thanks to Mark Miller and the authors of earlier proposals for help with the document and content! Finally thanks to a few intrepid early reviewers for their

Re: Weak Reference proposal

I'm happy to do whatever is appropriate here. Is there a message I should put in the Readme to emphasize the early stage? On Tue, Feb 16, 2016 at 4:38 PM, Mark S. Miller wrote: > > > On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith wrote: > >> I have no

Re: Weak Reference proposal

? > Doesn't this force he "hard" reference to also a soft reference "weak > reference" to insure that finalizer run (such as closing a file, etc)? If > aren't concerned about non-memory resources is there any point to having > holding at all? > > > > On Sun

Re: Feedback on Iterable Numbers Proposal?

A Range type seems to me clearer, more powerful, and less magical. Even without syntax, the clarity seems better: //for-of syntaxfor (const i of Range.upto(5)){ //do something with i } for(const i of Range.from(3, 15)){ //do something with i } Whether Range's are a class or it's just a

Re: Enable async/await to work on functions that don't just return promises.

> > Should `callee()` be asynchronous here? To my mind, no, it shouldn't. > Every single line here is synchronous, so the function itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async

weakref proposal update

This is just a heads up that the WeakRefs *presentation* has been updated with the improved API and semantics, based on various issues and discussions from the first version of the proposal. The new version is updated in place and is still at:

Re: weakref proposal update

at 10:35 PM, Dean Tribble <trib...@e-dean.com> wrote: > This is just a heads up that the WeakRefs *presentation* has been updated > with the improved API and semantics, based on various issues and > discussions from the first version of the proposal. The new version is > updated in

Re: weakref proposal update

*and* creation does not strongly preserve the Target until the end of the turn. On Fri, Mar 16, 2018 at 1:09 AM, Dean Tribble <trib...@e-dean.com> wrote: > We got another round of insurmountably good feedback, so I revised the > presentation again and am back to writing spec text. > &g

Re: weakref proposal update

er, by "it looks larger than it appears" I meant "it's smaller than it appears" or "it looks much larger than it is" or some such :). On Mon, Mar 19, 2018 at 5:21 PM, Dean Tribble <trib...@e-dean.com> wrote: > A first round of spec-text is now pushed for th