Before we implement SDL package format for DUB

[Jonathan Marler via Digitalmars-d]

> You said that "The standard way to read a dub package 
> description is to use the output of "dub describe", not to 
> parse dub.json directly", but what about tools that *write* to 
> dub.json? Currently, if an IDE wants to use DUB behind the 
> scenes as it's build system it can parse dub.json and modify it 
> as it wishes, and that should even work if someone modified 
> dub.json by hand. But what if someone modifies dub.json by hand 
> and adds ASON stuff to it? I think we need a command like `dub 
> normalize` that'll convert the dub.json file into a pure JSON 
> file that has exactly the same data, so IDEs could call it 
> before loading dub.json.
>
Good points...

>
> About the language - if you are making a new data serialization 
> language(NOT markup language. These languages don't actually 
> mark anything up) for DUB, could you please make it support 
> heredocs? This will allow, in the future, to easily add 
> pre-build and post-build scripts directly in the build-file.
>

I am not familiar with the term "herdoc".  After a quick google, 
it looks like it refers to a way of escaping the language.  Is 
this not something that a single-quoted string couldn't handle?  
You would still need to escape single-quotes and back-slashes, 
but it comes close.  However, I wouldn't be against adding a 
special character sequence to support this (Maybe '<<' or 
something).


> Alos - nameless fields scare me. They mean that ASON is not a 
> schema-less format - and schema-less-ness is one of the most 
> important features of languages like JSON, XML and YAML. I 
> accept it if consumers break when suppliers remove fields - but 
> nameless fields mean that consumers might break when the 
> supplier added fields in the middle or reordered fields. This 
> makes ASON a schema-bound format - and developers that choose 
> schema-bound formats, usually care about compactness that ASON 
> does not supply(since most the syntax is one of schema-less 
> formats, it's very verbose compared to schema-bound formats).
>

Yes when you start using nameless fields your data now needs a 
schema.  And I had the same concerns you mentioned when 
adding/removing fields. That's why I recommended the only fields 
that DUB should make nameless are the "name" fields on some 
objects.  However, this is not important, completely dismissing 
the nameless fields feature for DUB would be completely 
reasonable as well.

>
> At any rate, it would be nice to have the ASON parser as a DUB 
> package before making it the official language for DUB 
> build-files.

I'm writing it now for other projects of mine.