- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Wed, 4 Dec 2013 17:41:27 +0000
- To: Michael Luggen <michael@oiu.ch>
- Cc: "public-rdfjs@w3.org" <public-rdfjs@w3.org>
Hi Michael,
> What possibilities to access a parsed graph are there right now? What for sure is a needed feature for our visualization framework are more formats.
At the moment, only simple (but fast) { ?s ?p ?o ?g } access.
This might be enhanced with a fluent query interface in the future, maybe SPARQL.
Still deciding on that (and finding time to undertake something like that.)
> Another additional question, what kind of Design Pattern to use for libraries today?
Even though JavaScript offers prototypal inheritance and functional programming,
I deliberately choose the “class”-oriented way of programming.
Meaning: each file/module essentially returns a constructor of objects that do things,
and these constructors can potentially be inherited from.
The main reason for this is testing: there's not much crosstalk going on between modules.
I've been heavily influenced by Miško Hevery's articles on this matter (e.g., [1]).
> Also I like to start out with a code documentation right from the beginning. And am back and forth with usedocjs.org and simpler stuff like https://github.com/jashkenas/docco ?
I started out with docco from the beginning, and still use it on the library (discipline, you know).
However, I was too optimistic that this would be the only documentation people would ever need.
I believe people learn most from recipes, so this is how I structured the README [2].
Best,
Ruben
[1] http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
[2] https://github.com/RubenVerborgh/N3.js#parsing
Received on Wednesday, 4 December 2013 17:42:04 UTC