On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote:
Am 22.08.2014 18:15, schrieb "Marc Schütz" <schue...@gmx.net>":
Some thoughts about the API:
1) Instead of `parseJSONValue` and `lexJSON`, how about static
methods
`JSON.parse` and `JSON.lex`, or even a module level functions
`std.data.json.parse` etc.? The "JSON" part of the name is
redundant.
For those functions it may be acceptable, although I really
dislike that style, because it makes the code harder to read
(what exactly does this parse?) and the functions are rarely
used, so that that typing that additional "JSON" should be no
issue at all. On the other hand, if you always type "JSON.lex"
it's more to type than just "lexJSON".
I'm not really concerned about the amount of typing, it just
seemed a bit odd to have the redundant JSON in there, as we have
module names for namespacing. Your argument about readability is
true nevertheless. But...
But for "[JSON]Value" it gets ugly really quick, because
"Value"s are such a common thing and quickly occur in multiple
kinds in the same source file.
2) Also, `parseJSONValue` and `parseJSONStream` probably don't
need to
have different names. They can be distinguished by their
parameter types.
Actually they take exactly the same parameters and just differ
in their return value. It would be more descriptive to name
them parseAsJSONValue and parseAsJSONStream - or maybe
parseJSONAsValue or parseJSONToValue? The current naming is
somewhat modeled after std.conv's "to!T" and "parse!T".
... why not use exactly the same convention then? =>
`parse!JSONValue`
Would be nice to have a "pluggable" API where you just need to
specify the type in a factory method to choose the input format.
Then there could be `parse!BSON`, `parse!YAML`, with the same
style as `parse!(int[])`.
I know this sound a bit like bike-shedding, but the API shouldn't
stand by itself, but fit into the "big picture", especially as
there will probably be other parsers (you already named the
module std._data_.json).
