slightlyoff / Promises

DOM Promises IDL/polyfill
Apache License 2.0
154 stars 28 forks source link

Where to define the data passed. #29

Closed PaulKinlan closed 11 years ago

PaulKinlan commented 11 years ago

Firstly, sorry if this sounds stupid.

In my hackjob of a reworking of the Geolocation API, I am trying to determine where the values passed in to "then" or "done" are defined.

The Geolocation spec has http://www.w3.org/TR/geolocation-API/#position and http://www.w3.org/TR/geolocation-API/#position_error_interface objects which are only ever used when passed into the success or error callbacks.

I think (I could be wrong) that in the current model of DOMFutures, their usage in the spec is left hanging? i.e, they might be defined but there is no usage in the IDL for them.

Is it expected that authors will create a {X}Future IDL for their API by either specifiying that the accept callback takes a API{X} specific object, or that done and then will be defined more deeply for the API?

For example, Geo might have a GeoIDL of: dictionary Position { /* what ever the spec defines */ };

dictionary PositionError { /* what ever the spec defines */ };

callback GeoCallback = void (Position); callback GeoErrorCallback = void (PositionError);

interface GeoOperation : DOMFuture { void done(optional GeoCallback onaccept, optional GeoErrorCallback onreject); void then(optional GeoCallback onaccept, optional GeoErrorCallback onreject); };

Is this along the correct way of thinking or am I miles off?

domenic commented 11 years ago

Good question. I'll leave it to the real IDL users and experts to answer, but IMO this ties into #20; the nicest way for things to be would be something like

DOMFuture<Position> getCurrentPosition(optional PositionOptions options);
// rejects with PositionError

I am modeling this off synchronous IDL I have seen, which seems to go something like

Position getCurrentPosition(optional PositionOptions options); // throws PositionError
annevk commented 11 years ago

The IDL would be something like:

Future getCurrentPosition(... options);

(Maybe we'll get the fancy IDL notation if Future becomes a JavaScript type.)

Then in prose you'd define that the Future is accepted at some point in time and passed an object X. Or passed several arguments X, Y, Z, depending on how we want to model that. The Future specification will provide hooks.