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

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, August 15, 2012 5:47:23 AM UTC-6, Georg Bauhaus wrote:
> 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.

It was years ago, it might have been due to still being controversial, it may also have have been the Java documentation was wrong, and, yes, I could have been recalling wrong.

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

I'm using my own experience as a gauge; it is incorrect to not consider experience as fact. -- True, my perceptions color things, but you simply cannot say that the experiences didn't happen.

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

Agreed. INI files would be horrible for storing the state of a simulation, as would most text-based files, also it would not suit data which is hierarchical like object-serialization (in particular the 'has-a' relation). 

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

I would agree; though there are problems about not-thinking in [my experience] in the field (granted, I was doing web-site backend stuff).

> Nevertheless, this frees the other end from having to deal with foreign
> internals.

Which is not a bad thing; good tools allow the user to concentrate on the job rather than on particular irrelevancies. I don't like working on *nix systems precisely because of this problem: the irrelevancies get in the way much too often. (File-permissions is a good example; the one and ONLY time I've had a file-permission issue get in the way of working on a Windows-system was under a *nix subsystem port [Ming].)

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

As we're talking of XML in particular, I should think the second is the only class we really need to worry about. (Failure on the first would indicate a failure on transport or decoding-to-text; i.e. exceptional circumstance.)

> 
> > 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" />

This is trivial, but indicates a problem about the XML format: it assumes everything to be a tree. Element gnorplx here is representing an entire section of the given INI -- the key-value pairs though should be leaves themselves of the section-object.

INI files have a different problem: they assume things to be non-hierarchical, key-value pairs divided into sections.

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

Er, that's a pretty bad example. It's like saying you CAN serialize objects into INI-format w/o considering the consequences of that decision. Indeed, that's been my main underlying point here: XML carries with it implicit costs, it is *not* the best solution for every problem. {It is my opinion that there are very few problems that it actually does solve nicely: object-serialization is one where I think it is adequate. (Though, as CombatXXI shows, it may be unsuitable for that due to constraints.)}

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

Ive not seen "efficiency" *ever* cited as a choice's decision-factor for either CSV or INI -- I have, however, seen "portability" and "simplicity" cited. {Especially in CSV vs Excel's binary decoding for importing data into a system.}

> 
> My favorite example: CSV without record separators
> (hint: use counting).

Yeah, I haven't encountered CSV w/o record separation... I have encountered the other-way that makes record separators irrelevant though: data across multiple rows for a single record -- Which is why people who use spreadsheets when they should be using DBs ought to be beaten. {I say that having had some little experience on the Army's admin side: what a nightmare of using the wrong tools for the job.}