Reflection to know if executed within a generator/async ?
isiahmeadows at gmail.com
Mon Dec 7 08:26:24 UTC 2015
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
>>> 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,
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss