Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 14.08.12 22:30, Shark8 wrote:

> the presence/absence of that single [optional, according to the documentation, IIRC] attribute caused the whole thing to fail.

You don't remember correctly.

Namespaces used to be controversial, but an Ada-like solution
has been adopted by XML.

>> Wow. At least witty commentary compensates for the lack
>> of understanding of the basics of XML.
> 
> What's there to understand when you're evaluating it as a container?
> Take config-files, they're usually much better stored in an INI file.

Both "usually" and "much better" need facts to back them up.
If two heterogeneous systems need to exchange configuration
data, whether or not INI files will work well, or not at all,
or something in between, will depend on the configuration data.

> About the only thing I can really envision XML being appropriate for, and this is likely a stretch, would be serialization of [OOP]  objects where the tag would be either an object or a primitive type, a primitive type being self-closing and having a value attribute where the object-tag would enclose tags corresponding to its own fields (either object-tags or primitive-tags themselves)... of course that pretty much just described the text-format DFM files Delphi uses (which I like more because of their readability and philosophy of "if it's the default, don't save it" which is sadly missing from a lot of config/state/obj serializations).

While XML is being used for serialization between heterogeneous systems,
I guess that's probably because programmers have tools for turning
internal data objects into serialized form for external use, apparently
freeing them from thinking, and apparently saving some work at some point.
Nevertheless, this frees the other end from having to deal with foreign
internals.

> Though if you meant the emphasis of readability was not the same I would agree: XML is skewed toward the machine away from the human, at least in use.

Yes I meant "technically possible to read without additional
tools, everywhere".

>> Readable in the case of XML
>> means something more plain, something more technical:
>> that anyone can read XML documents using a pair of
>> eyes and a program like "more". No knowledge of any other
>> language is required, no knowledge of bit patterns is required.
> 
> And that's where XML often fails. Sure you "can*, as in might be able to, operate an XML file with a plain-text viewer -- but again, once there's any real-life complexity, then the relevant information [the signal] is quickly lost in a sea of noise.

Again, these claims would profit from facts to back them up:
Here is one. The real-life situation is exchange of data.
You need to debug one such exchange.
If (1) you get to see a stream of bits, what do they mean,
where is the error?
If (2) you get to see a structured text, what do the words mean,
where is the error?

> This is why INI files beat XML as config files: there is so little noise built into the format of "sections containing key/value pairs."

In this case, your ini files would be trivial, and your XML files would
be a product of thoughtlessness. Both are related to quality of work and data,
they do not imply properties inherent to either format,
as can be seen by actually comparing equals in either format:

[gnorplx]
foo = 42
thrndx = 1m

<gnorplx
  foo="42"
  thrndx="1m" />

Big deal? -- If the XML file should look even more like an INI
file, if your eyes sting when they see angle brackets in plain
text, then with a suitable SGML declaration for a config document,
the aesthetically offended programmer can write

[gnorplx]
foo = 42
thrndx = 1m

in SGML.

>> Nor is XML intended for internal data formats.
> 
> That doesn't stop people from doing so; I've seen it in web-programs and desktop apps (a lot more now that MS-Office's *.???x format is widespread).

Nor does the attribution of simplicity to INI, CSV, etc.
stop people from storing a ton of brittle implications
in these files, sometimes pointing out efficiency.
My favorite example: CSV without record separators
(hint: use counting).