Skip to content

Promise support #132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LaurensRietveld opened this issue Apr 24, 2018 · 8 comments
Closed

Promise support #132

LaurensRietveld opened this issue Apr 24, 2018 · 8 comments
Assignees

Comments

@LaurensRietveld
Copy link
Contributor

What's the opinion on supporting promises in addition to callbacks? It would change some return types (as some callbacks return more than one value), but it would make for better integration into modern js codebases.
Guess we should keep it optional though, as there might be a performance penalty.

Ps. Great to see n3 as part of the rdfjs project now 👍 .

@RubenVerborgh
Copy link
Member

Interesting you mention this, I'd been thinking about this today myself (after writing some async/await code).

One consideration is that N3.js is still written in ES2015. This project started in the old days before transpiling, so browser compatibility was a big thing for me back then. I guess I could safely write it in a more modern JavaScript dialect now, and only transpile when strictly necessary. And Promise should be standard everywhere by now.

Then there's indeed the question of overhead. It should be negligible, but N3.js tries to be very low-level to avoid any such overheads. I might offer it as a secondary interface: if no callback is passed, return a promise. (Or I could just go all the way and write the code with async functions so I don't have to bother about explicit promises.)

But then the real question is: where would we use promises? Because most of the callbacks are used for streams of data. For instance, the parser works with a callback, but that callback is fired multiple times, in contrast to a promise that can only resolve once. Where would you find promises useful?

@bergos
Copy link
Member

bergos commented Apr 24, 2018

With the Stream interfaces there are really not so many places to convert callbacks to Promises. But RDF-Ext has a function and a method which could be quite useful as part of RDFJS:

  • .waitFor just wraps the end and error events into a Promise (example)
  • Dataset.import also wraps end and error but returns the Dataset itself (example). The RDFJS spec doesn't contain an interface like the RDF-Ext Dataset or N3.js Store, but it could make sense define it in an additional spec.

@LaurensRietveld
Copy link
Contributor Author

But then the real question is: where would we use promises? Because most of the callbacks are used for streams of data. For instance, the parser works with a callback, but that callback is fired multiple times, in contrast to a promise that can only resolve once. Where would you find promises useful?

Situations where:

  • I have a limited amount of triples
  • I want a simple interface for parsing/serializing triples (streams are nice, but don't like their interface tbh)
  • I don't want to synchronously parse/serialize them

It's not a typical use-case, but I've enountered it a few times before (i.e. I've already wrapped the parse/write functions as a promise a few times)

@RubenVerborgh
Copy link
Member

I want a simple interface for parsing/serializing triples

I get that one, and interestingly, I did that yesterday by awaiting the stream rather than the parser:

const document = await fetch(source);
const parser = new N3.Parser({ baseIRI: source });
const quads = parser.parse(await document.text());  // <= parsing is simply sync

BTW These days, the above code runs natively in the latest Firefox and Chrome without transpiling.

I don't want to synchronously parse/serialize them

I don't get that, why wouldn't you want sync when it is possible? 😄
I get the constraint if you can't parse synchronously, but that's what I solved above by awaiting the input rather than awaiting the parser.

@LaurensRietveld
Copy link
Contributor Author

Ha, you're right, that doesn't really make sense. Reason for my confusion: the current synchronous implementation of the parser returns less information than the callback gives you. A promise implementation that returns the same info as a callback would be nice, but it'd be even better if the synchronous return value contains that information.

@RubenVerborgh
Copy link
Member

the current synchronous implementation of the parser returns less information than the callback gives you

You mean the prefixes? That would be #123, which I indeed should get into v1.0.0 now that I can break the interface because of the major version dump.

@LaurensRietveld
Copy link
Contributor Author

Ah, that'd be great.cant think of a valid use case for promises then, so feel free to close

@RubenVerborgh
Copy link
Member

Alright, thanks for the discussion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants