Reflection to know if executed within a generator/async ?

Isiah Meadows 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
>> 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


More information about the es-discuss mailing list