it should be possible to configure the parser with data
Closed this issue · 2 comments
bpsm commented
I'm thinking of something like:
Parser p = Parsers.newParser(…);
Parseable r = Parsers.newParseable( … );
Parser.Config cfg = (Parser.Config) p.nextValue(r);
Where the Parseable r
reads edn that's something like this:
#bpsm.edn-java/parser-config {
:listFactory #bpsm.edn-java/class "fully.qualifed.class.Name"
;; new fully.qualified.class.Name() returns a CollectionBuilder.Factory
…
:handlers {
:my/base64 #bpsm.edn-java/method {
:class #bpsm.edn-java/class "fully.qualified.class.Name"
:name "staticFactoryMethod"
}
;; fully.qualified.class.Name.staticFactoryMethod()
;; returns a TagHandler.
…
}
Open design questions:
- the example above makes heavy use of tags, distributing the work of parsing the configuration between the
parser-config
,class
, andmethod
tags. An alternative that leaves out the inner tags for brevity preferring instead to pack the knowledge into the handler forparser-config
is conceivable. - the prefix
#bpsm.edn-java
is just made up. Convention elsewhere in the code base is to use#info.bsmithmannschott
, but that's rather long -- though it's certainly unique.
mikera commented
Nice idea!
I'm wondering if there is / should be an edn-wide standard for how these kind of tags are named? The edn spec isn't particularly specific - only says that the prefix should "must be owned by the user (e.g. trademark or domain) or known unique in the communication context".
In this case, since the domain is controlled, you can safely use any prefix you like if the spec is to be believed - e.g. just #edn-java/method
would be fine I think.....
bpsm commented
don't intend to implement