Class decorators and async process

Alexandre Louis Marc Morgaut alexandre at morgaut.com
Wed May 27 08:10:52 UTC 2015


> On 26 May 2015, at 01:09, Brendan Eich <brendan at mozilla.org> wrote:
> 
> Gray Zhang wrote:
>> 
>> It’s OK, I just wait for |this.weapon| to resolve, but then my |hit| method becomes async, and everything based on |@inject| property should be async, which is not actually what I want.
>> 
> 
> Async can be contaminating, yes.

That’s exactly a point that reached my interest in the given example

My brain looking at this contamination wondering things like:
- Then we would need “await @inject(‘knife’)” ?
- Then we would need “async class Hero {…}” ?
- Then users should take care to do “await new Hero()” ?
- and/or would it mean that we could do instead “class extends Promise { … }" ?

Ok… Are async Classes / Constructors crazy or just natural evolutions we could/should be prepared to see in the future !?

Just wondering, I’m curious, I’d understand either that to be crazy or natural ;-)


> Sync is out of bounds in browsers, and for Node.js apart from require -- a rift indeed between the two embeddings.

Just to be fair, Sync is still appreciated in some situations in JS like
- in Dedicated Workers, 
- in other SSJS platforms like RingoJS, Wakanda, APE, …
- as it is also in Node.js when writing CLI applications (then tricks are occasionaly used in addition to Sync APIs) ;-)


Regards,

Alexandre


More information about the es-discuss mailing list