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