-
Notifications
You must be signed in to change notification settings - Fork 139
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
Comments
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 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 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? |
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: |
Situations where:
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) |
I get that one, and interestingly, I did that yesterday by 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 get that, why wouldn't you want sync when it is possible? 😄 |
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. |
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. |
Ah, that'd be great.cant think of a valid use case for promises then, so feel free to close |
Alright, thanks for the discussion! |
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 👍 .
The text was updated successfully, but these errors were encountered: