Before we implement SDL package format for DUB
Nick Sabalausky via Digitalmars-d
digitalmars-d at puremagic.com
Fri Aug 29 03:18:52 PDT 2014
On 8/28/2014 5:07 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:
>> On 8/28/2014 5:29 AM, Kagamin wrote:
>>> and the only way
>>> to make them scale is to turn them into syntactical equivalent of XML
>>> with closing tags. And even then more verbose than XML itself. So what's
>>> a difference from XML if good config language still must have XML
>>> syntax?
>>>
>>
>> The differences (off the top of my head, there may be more):
>>
>> - Nobody has to actually write the closing
>> - Nobody had to keep the opening/closing in sync
>> - The closing takes up zero bytes
>> - Nobody has to actually look at the closing if they want to reduce
>> the visual clutter: Ie, viewing it is an optional thing.
>
> So it has no advantage over using a grammar-based XML editor, just less
> flexible and more clumsy… Sounds like the wrong trade-off.
>
I could easily turn that around and say a grammar-based XML editor has
no advantage over my suggestion. I certainly don't see what's "less
flexible" about it. And I find some of the tricks that grammar-based XML
editors do to be clumsy and in-my-way (specifically when they
automagically insert text I didn't type).
*Without* any editor support, JSON-style and XML-style both have pro/con
tradeoffs. I prefer the JSON-style tradeoffs.
*With* an ideal level of editor support, JSON-style and XML-style can
pretty much reach feature parity.
I still hate dealing with XML though ;)
> (tags don't take much space when the file is compressed)
>
If it really needs to be compressed, then the format may be too verbose
anyway. It doesn't really strike me as passing the "less clumsy"
criteria either. Ehh, but I'm a fan of binary for interchange anyway, so
whatever ;)
More information about the Digitalmars-d
mailing list