Re: Hybrid promises

Thanks, Jeffrey

Wrapping the interface to remove the promises as you suggest will work from a developer style perspective, but the underlying implementation would still need to return promises.
A wrapper would also change the interface reducing the portability of code between implementations.

For example, implementing a web-bluetooth API in node would require a dependency on a promise library (such as es6-promise) even if the api is later wrapped and the promises not used.

I'll repost my question on the other list, but as the API is targeted for the web I can see how this is unlikely to change.

Kind regards,

Rob

________________________________________
From: Jeffrey Yasskin <jyasskin@google.com>
Sent: 23 September 2015 18:28
To: Rob Moran
Cc: public-web-bluetooth@w3.org
Subject: Re: Hybrid promises

This may be more of a question for public-script-coord@w3.org, who
govern the style of new web APIs. My understanding is that every new
API is using Promises, and folks who want to adapt them back to
callbacks can wrap them, just like folks who want to use Promises with
old callback-based APIs have to wrap them.

https://github.com/hybridables/promise2thunk looks close to what you
want, but it works on the output of the function instead of
transforming the function itself. Would a similar wrapping library do
what you want?

We haven't explicitly considered defining a hybrid API that accepts a
callback and returns a promise, but I expect most web API experts will
oppose that direction, since the web platform will have to keep
supporting it even after everyone's switched to promises.

Jeffrey

On Wed, Sep 23, 2015 at 10:04 AM, Rob Moran <Rob.Moran@arm.com> wrote:
> Hi group,
>
>
> we've been following the web-bluetooth specification closely with interest
> and with a view to implementing it as an abstraction interface over other
> popular JavaScript-BLE implementations on web, server and mobile.
>
>
> We are aware this is a web-bluetooth specification rather than
> JavaScript-bluetooth, however it does rely heavily on the use of ES6
> promises, a paradigm not commonly used on many platforms (yet!).
>
>
> Promises are an elegant approach to asynchronous programming, but even in
> web development the use of promises could perhaps be considered a choice of
> the developer and not forced by the API.
>
>
> We were wondering if a hybrid approach was considered when defining the
> specification which allows the choice of using promises (if available) or a
> callback with an error object.
>
>
> Examples of this approach can be seen in these npm modules:
>
>
> https://www.npmjs.com/package/hybridify
>
> https://www.npmjs.com/package/handle-callback
>
>
> Forgive my ignorance if discussions around this are already public.
>
>
>
> Kind regards,
>
>
> Rob
>
>
>
> ________________________________
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.


________________________________

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Received on Thursday, 24 September 2015 09:54:15 UTC