Before we implement SDL package format for DUB

[Idan Arye via Digitalmars-d]

On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler wrote:
>> 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).

Heredoc, after parsed, is no different from a regular string. But 
isn't ASON as well, after parsed(with schema), is no different 
from regular JSON?

As far as I understand, the point of ASON is to make the build 
files more human readable and writeable. Heredoc do the same 
thing - if you have a long script(a shell script, or one in a 
hosted scripting language, or even D code that'll be ran with 
rdmd) it's hard to write it in a regular quoted string, because 
they don't support newlines(you have to use '\n') and you need to 
be careful not to use the quote in the script itself(unless you 
escape them). Heredoc makes writing these scripts more 
straightforward.


>> 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.

Using the nameless fields in DUB is not the problem - DUB has a 
well defined schema with a well defined single source of 
authority. If you want to see ASON used as a data transfer 
format(like JSON) then these nameless fields will be problematic.