Re: Hybrid promises

Note that Luiz Montes is working on an implementation of the noble API in
terms of Web Bluetooth:
https://plus.google.com/+LuisMontes/posts/4BJ8zWdagTR. If node apps prefer
that API because it matches existing Node code better, I think it's fine
for them to use it.

Node also has native Promises since the 4.0 merge.

I don't mean to scare people off from API feedback in general. We'll
strongly consider any "this change would make this concrete use case work
better" feedback, especially if it comes with example code proving the
point. It's just that the Promise switch is bigger than this one API.

Thanks,
Jeffrey

On Thu, Sep 24, 2015 at 2:53 AM, Rob Moran <Rob.Moran@arm.com> wrote:

> 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.
>
>