Issue #45: Add missing spec methods to DataFactory interface

[matthieubosquet]

As per issue #45 the fromTerm and fromQuad DataFactory methods defined by the RDF/JS DataModel specification are not reflected in the @rdfjs/types package.

This PR adds those methods.

That said, I am unsure in which context those methods would be used and didn't find an explanation of when it would be or whether the omission is intentional.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: cfc4d28422d102ab0ed316e819fef5efa69f09ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@rdfjs/types	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jeswr]

Hi @matthieubosquet :)

Thanks for these changes! It may be worth using a mver bump to release these changes, as many RDF/JS implementations do not implement these methods (c.f. https://github.com/rdfjs/N3.js/issues/447) - and so this will either cause (1) the package to declare methods that it does not implement or (2) have type errors if the package is, e.g., written in typescript and implements the DataFactory interface.

[matthieubosquet]

Rebased and made this a major bump: https://github.com/rdfjs/types/pull/46/commits/b0ca1a94a9735e56711ffca92c3202b9e5f5af28.

I am not sure what is the release process and how to publish a v1.1.1 (maybe before merging this).

I also wonder if maybe we could add a few items before potentially publishing a version 2.0.0:

1. simplify the release process, document it and update the publish action accordingly (it feels like changeset and yarn might be a tad overkill and extra tooling to learn)
2. update dependencies (typescript at least, hopefully eslint too)

[tpluscode]

If we want to simultaneously work on v2 then we'd probably need a dedicated branch...

[matthieubosquet]

Thanks for the suggestions @tpluscode and @rubensworks!

I fixed up the tests after applying suggestions: https://github.com/rdfjs/types/pull/46/commits/f1879fbe4b141efacd433ef16e34883b5d65119a.

The DataFactory initialised with const dataFactory: DataFactory<BaseQuad> = <any> {}; was returning a BaseQuad, not a Quad, hence CI failure.

[matthieubosquet]

After @jeswr's comment, I realised that there might be a bit of inconsistency in the DataFactory method declarations and its use of generic types.

In a nutshell, with a typing such as: fromTerm<T extends NamedNode>(original: T): NamedNode;, the DataFactory would take in an extended NamedNode and produce a NamedNode. I don't think that's what we want for DataFactory implementers. With a typing such as: fromTerm<T extends Term>(original: T): T;, if we pass an extended NamedNode to the DataFactory, it will return the extended type which still can be cast to a NamedNode (see corresponding test). Isn't it closer to what DataFactory implementers might want?

---

I tried to produce a commit that illustrates and offers a compromise to fix the issue.

---

Remains an inconsistency with the quad factory part: We are currently offering to define InQuad and OutQuad as anything that extends BaseQuad. That allows us to be specific as to what the DataFactory consumes and produces (as far as quads are concerned).

If we allow that amount of specificity for Quads, is there a specific reason not to allow it for other Terms?

[jeswr]

I don't think that's what we want for DataFactory implementers.

I think I see where you're going, but this solution doesn't quite work. Consider using fromTerm from @rdfjs/data-model with an input of an N3.js NamedNode. The N3.js NamedNode has an extra #toJson method that will not be available in the NamedNode output by the @rdfjs/data-model method; however the type inference you have now would suggest that the output NamedNode does have this #toJson method.

What you want to allow for is for the libraries to extend the DataFactory types such that any custom extensions they have to their terms can be included - that is fromTerm from N3.js will always output a NamedNode with the #toJson method regardless of whether the input NamedNode does or not. Your original implementation should permit this.

[tpluscode]

To demonstrate the problem, here's see this playground link with the generic function.

Here's what @jeswr described. The var converted is typed as NamedNodeExt which is probably incorrect.

[tpluscode]

I think it's worth mentioning the PR #24 which could allow implementors to define concrete term subtypes returned by a data factory

@blake-regalia would you interested in picking up where we left that?

[jeswr]

@tpluscode and any interested others in this thread; could you please review https://github.com/DefinitelyTyped/DefinitelyTyped/pull/70614

[matthieubosquet]

@tpluscode does that look alright to you?