Before we implement SDL package format for DUB

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 26 03:18:11 PDT 2014


Am 25.08.2014 18:40, schrieb Jonathan Marler:
> Hello everyone,
>
> I've been working on SDL support for DUB and wanted to get some people's
> opinions on whether we should really use SDL.  I've posted my thoughts
> here:
> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

Just sharing my (overdue) more detailed view on this:

Pros:
  - Easier to parse
  - Slightly nicer handling of "enum" values due to quote-less strings
  - Whitespace insensitive

Cons:
  - I *really* dislike the "application specific"/"nameless tags" part
    of it, because generic handling always was one of the basic
    prerequisites for me
  - It's a still custom format in practice, even without the "application
    specific" part - except if it (ever) becomes more widespread
  - Confusing wealth of syntax possibilities when punctuation can be
    omitted, I'd very much prefer one way to express one thing
  - A language with neither newline sensitivity, nor required tag
    terminators, I think is bound to give very bad error message in
    certain situations
  - Quote-less strings, especially when mixed with nameless tags or
    omitted punctuation can be very confusing
  - Quote-less strings which are allowed to contain punctuation are
    confusing, because the punctuation can easily be confused as being
    part of the ASON syntax itself

To me, this currently outweighs by far the disadvantages that SDL has:

  - Sensitive to newlines, but not other whitespace. This is convenient,
    although I'd prefer a mandatory semicolon (which ASON doesn't have
    either)
  - Some parser complexities not needed for DUB (e.g. date/time types).
    I'm more or less "meh" about this. It can be nice to have for other
    uses (configuration files) and doesn't really hurt either.

But most important is that SDL is already in use for other (non-minor) 
projects [1] and thus has probably much better chances to become more 
widespread than "yet another JSON extension format" (this is not 
critique of the approach of extending JSON, but rather of how the 
average observer would likely perceive a format advertised that way).

Continuing on that point, an important point for choosing a format was 
to minimize the amount of DUB specific syntax to learn. So if somebody 
has to learn a new language for that, it should at least also be useful 
in other places and any newly invented format is just much less likely 
to generally useful than something that already has some level of 
popularity.

[1]: http://sdl.ikayzo.org/display/SDL/Projects+Using+SDL


More information about the Digitalmars-d mailing list