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