So I understand the proposal what exactly is `window.callback.getCatch()`? Is window the reference to the global object created in a browser context? Since this group is for ECMAScript discussions referencing window, I think, would be out of the question in this scope (perhaps more appropriate as a WHATWG recommendation).
Or is window simply holding the callback yourself using (so essentially removing the reference to `window` would keep your proposal the same)? If so functions in ECMAScript can hold properties and other functions so this could create a collision. If the ultimate goal of this proposal is to allow the try catch pattern to work across asynchronously executed code then I think await is really your answer here. I think anything else may be a bit too complex though I'm certainly open to hearing any ideas (not that my opinion technically matters in that regard 🙂). On Tue, Jun 21, 2016 at 6:49 PM, Todd Hubers <[email protected]> wrote: > Good questions Tab > > 1. Mixtures of async/await and callback code. As much as you want purity > it doesn't always happen. > 2. Related to the previous question. Those who have mixtures of > async/await and callback code. > > I've used await a lot in C#/.NET, it isn't the cure of the diagnosed > callback disease, but it is a great treatment. In some coding scenarios I > have found the await keyword to be more cumbersome than callbacks. This > could be due to the way C# implements it - all functions which await must > return a Task object, and if the method is decorated with async, it must > await. In .Net it's multithreaded and not an event loop by default, so it > can be more complicated. I was building a TCP server recently with C# and > gave up, ripped out all the async/await and replaced with callbacks. It was > so much easier. > > I don't have academic references handy which would back up my claim that > "await doesn't solve all async problems, and can actually work against you > in some scenarios in ES". Perhaps there are others who can support me on > this front. > > > > Sent with MailTrack > <https://mailtrack.io/install?source=signature&lang=en&[email protected]&idSignature=22> > > Regards, > > Todd Hubers (BBIT Hons) > Software Engineer > > Contact <http://alivate.com.au/todd/> | Availability > <https://www.google.com/calendar/[email protected]&ctz=Australia/Sydney> > > On 22 June 2016 at 11:37, Tab Atkins Jr. <[email protected]> wrote: > >> On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <[email protected]> >> wrote: >> > 1. Whether you await or not, the try scope's catch callback [TSCC] >> should still be captured. >> >> Why? Async code doesn't do anything special for try/catch anywhere >> else in the language - what does this proposal do that's worth the >> added complexity beyond what just using a Promise and the await/async >> keywords can do? >> >> > 2. If there is no use of Promise (for coders own design reasons) the >> try scope's catch callback [TSCC] should be available >> >> What uses are you thinking of, and why should this be available? >> >> ~TJ >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
