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.
