I've never said they shouldn't, the only example I gave was `require` which is a very specific use case. We can talk about everything else as much as we like but it would be irrelevant for this post or regarding what I was thinking about ;-)
On Mon, Dec 7, 2015 at 8:26 AM, Isiah Meadows <[email protected]> wrote: > Andrea, it's one thing to either return a Promise or use a callback, > depending on the existence of the callback, but I get the impression > the discussion is about difference between fs.readFile and > fs.readFileSync, and why those should be separate functions. > > On Mon, Dec 7, 2015 at 1:48 AM, Andrea Giammarchi > <[email protected]> wrote: > > 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 <[email protected]> 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 > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > Isiah Meadows >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
