I've asked for opinions and if in 2 days I haven't replied means I got it my idea is not welcome which is OK and fair enough.
However, I'm curious to know about this "Functions that sometimes return promises and sometimes not are already known to be an antipattern" because I have a library that does that in somehow explicit way (if you pass a callback it doesn't return a promise, it invokes such callback once resolved) and it works without any real-world problem. Mind pointing me at the library that failed returning Promises arbitrarily? On Mon, Dec 7, 2015 at 12:48 AM, Bergi <a.d.be...@web.de> wrote: > Andrea Giammarchi schrieb: > > simply adding >> async and await and the only change to do in a well known/used >> *synchronous* API would be to check if the returned value is held and >> behave accordingly? >> > > No, making a consumer of an API asynchronous should not be simple. Unless > you are only writing pure functions, everything that involves states will > very likely break. Concurrency is not trivial, it needs a lot of > consideration. > > as soon as you go for >> async/await or a generator that function will return a Promise for you. >> > > Please never do that. Functions that sometimes return promises and > sometimes not are already known to be an antipattern. Making this obscurely > dependent on some fragile syntactic conditions could only make this worse. > > If you want to migrate your library to asynchrony, just make it a breaking > change. Your consumers will thank you for it. > > Kind regards, > Bergi > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
