Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
victor felder
@vhf
The way I see DataFactory is as a utility. I think we could live without but I also think it's often useful to have this object you can pass around.
@awwright If I understand correctly you are saying two things:
  1. Why do we need DataFactory / why is it spec'd that way?
  2. Why isn't [Constructor] used for the interfaces 2.1 to 2.7?
Austin Wright
@awwright
@vhf Yeah; I'm not a huge expert but it definitely appears to diverge from what I would expect an interface to define
And I say that because... my implementation didn't implement the factory interface until recently: https://github.com/awwright/node-rdf (and it's still unpublished to npm), I've always expected people to call new Interface directly
elf Pavlik
@elf-pavlik
@awwright please see https://github.com/rdfjs/stream-spec/pull/10/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR142
having one object to pass around works very well, how would you imagine to do that with bunch of constructors?
Austin Wright
@awwright
@elf-pavlik Would that be a kind of dependency injection?
My suggestion would just be to have an optional parameter with an object of the interfaces; this would default to window (for Web browsers; and would be supplied with a module reference for Node.js etc.)
Tomasz Pluskiewicz
@tpluscode

default to window

I don't think it's a good idea to rely on the window object

Austin Wright
@awwright
Well that's not really our call to make, that's just how WebIDL works
elf Pavlik
@elf-pavlik
with native ES modules in all browser I also would not depend on any globals which didn't ship with the browser
@awwright what do you mean by 'object of the interfaces'
Austin Wright
@awwright
Or maybe "object of the constructors"... Right now the factory has lowercased function names for camelcased interfaces
Perhaps we can solicit some advice on how to define standard interfaces in ECMAScript modules & Node.js modules
elf Pavlik
@elf-pavlik
what advantage do you see in having constructors over having factories ?
Austin Wright
@awwright
@elf-pavlik Certainly there's different ways to do it, my implementation is specifically designed so you can use RDF as a native built-in of the application; comparable to DOM API support
elf Pavlik
@elf-pavlik
and how current DataFactory definition affects how your implementation works together with other modules implementing RDFJS interfaces ?
Austin Wright
@awwright
@elf-pavlik I'm not sure exactly the technical advantages but alignment with other specifications would be nice
victor felder
@vhf
What other specifications are you thinking about? Examples would help (me) understand what you suggest and why
elf Pavlik
@elf-pavlik
@awwright does your implementation allow applications using it to provide it with factory of their choice ?
Austin Wright
@awwright
Like if I do require('rdf') I should get a module with NamedNode, etc functions
And I can pass this as an option for dependency injection
elf Pavlik
@elf-pavlik
now one can do const factory = require('@rdfjs/data-model') and pass factory around
Austin Wright
@awwright
@vhf Any specification that uses WebIDL... DOM API, IndexedDB, WebSockets API, WebRTC API, Bluetooth, ...
elf Pavlik
@elf-pavlik
only difference seems with how one would use that 'object of the interfaces'
factory.namedNode('https://foo.example') vs new rdfjs.NamedNode('https://foo.example')
victor felder
@vhf
(you could even const {namedNode} = require('@rdfjs/data-model') and not use the factory object)
Austin Wright
@awwright
@elf-pavlik Well typically if you call a constructor as a function it returns a new instance of itself; String("foo") is functionally the same as new String("foo")
victor felder
@vhf
Looking at https://www.w3.org/TR/IndexedDB-2/#factory-interface , the fundamental difference is that IndexedDB is supposed to be implemented by browsers (it's a browser API, not a JS one), that's why it's accessible on window. I might be missing your point though
Austin Wright
@awwright
Though personally, I prefer the new form because it's more transparent to the developer about what's going on (it's probably going to generate a new instance of that interface)
victor felder
@vhf
Note that new String('foo') and String('foo') are different
elf Pavlik
@elf-pavlik
store.match(null, null, new NamedNode('https://foo.example/bar'))
vs
store.match(null, null, namedNode('https://foo.example/bar'))
victor felder
@vhf
> new String("foo")
[String: 'foo']
> String('foo')
'foo'
> String('foo') === String('foo')
true
> new String('foo') === new String('foo')
false
> String("foo") === 'foo'
true
> new String("foo") === 'foo'
false
Austin Wright
@awwright
I see
elf Pavlik
@elf-pavlik
actually I find that new inconvenient if one created instance somewhere else than when declaring variable
Austin Wright
@awwright
I've actually implemented IndexedDB on Node.js and submitted implementation feedback, Since then IndexedDB 2 was released; but note that the factory is producing objects anchored to some origin; the same way document.createElement() creates elements anchored to some document
Also it's a bit more careful in how it defines the interface; note it's using partial interface
elf Pavlik
@elf-pavlik
I haven't dive too deep in WebIDL but possibly we might want to use partial interface since we expect implementations to extend them
@awwright maybe you can suggest fix for ReSpec error visible on top right in https://rdf.js.org/stream-spec/

Failed to parse WebIDL: Syntax error at line 7, since interface Store: Store implements Source; ^ Unrecognised tokens.

I think implements got deprecated in WebIDL

Austin Wright
@awwright
@elf-pavlik Yeah, I'm no expert but I'd be happy to look into it
victor felder
@vhf
We might also want to use [NewObject] https://www.w3.org/TR/WebIDL-1/#NewObject
elf Pavlik
@elf-pavlik
but I don't think we can define Sink and Source as mixin since they have direct implementations
I agree that WebIDL definitions may need some polishing, if you have specific suggestions I think PR would work best to get them in
Eric Prud'hommeaux
@ericprud
@bergos, i see your name on the rdfjs/dataset-spec@85d6e3b commit to the dataset spec.
Eric Prud'hommeaux
@ericprud
was the intention that?:
  1. Both this and the argument are mutable datasets.
  2. Both this and the argument will have blank node labels rewritten per RDF Dataset Normalization. These changes will result in datasets that are graph isomorphic to the originals.
  3. Apart from blank node rewriting, no other changes, e.g. .add() or .delete(), will occur in these datasets.
Eric Prud'hommeaux
@ericprud
One commitment I'm looking for is whether a caller can count on .equals() performing normalization. .toCanonical() appears not to canonicalize the supplied graph, merely supply a string representation of a canonicalized copy of it.
victor felder
@vhf
The intention is that the argument should be treated as an immutable dataset. It would be impractical to require implementations to enforce this, hence these notes: https://rdf.js.org/dataset-spec/#dom-dataset-equals
I think this discussion is relevant to your question: rdfjs/dataset-spec#23
victor felder
@vhf
That part of the spec is still WIP, any input is welcome on this. My implementation of equals compares the toCanonical version of both but this might change. toCanonical doesn't canonicalize the graph, that's correct, similar to toString
Eric Prud'hommeaux
@ericprud
so in your implementation, there's no apparent rewriting of bnode labels in either this or the argument?
victor felder
@vhf
I think toCanonical does rewrite bnodes, it uses https://github.com/digitalbazaar/rdf-canonize under the hood