Reflection to know if executed within a generator/async ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Dec 7 09:27:58 UTC 2015


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 <isiahmeadows at gmail.com>
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
> <andrea.giammarchi at gmail.com> 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 <a.d.bergi at 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 at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Isiah Meadows
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151207/08de7c49/attachment.html>


More information about the es-discuss mailing list