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

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

On 22.08.12 19:44, Dmitry A. Kazakov wrote:
> On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote:
>
>> On 22.08.12 16:30, Dmitry A. Kazakov wrote:
>>
>>>> As always, the question is inefficient for what and for whom.
>>>
>>> For the network and the peers. The measures for both can be easily
>>> provided.
>>
>> Well, that would depend on the specifics of "network" and its mode
>> of use, wouldn't it?
>
> There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so
> on.

In the set called "and so on", information retrieval programs will
be efficient at all once they can interpret a data item to be an object
for which FLOPs make any sense. That's easier to see when there is
markup than when the program needs to guess if some four octets
could be a float.

>>>>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
>>>>
>>>> ?
>>>
>>> Take Containers.Doubly_Linked_Lists as an example. The closure object of a
>>> list is the structure in question.
>>
>> "closure object" = ?
>
> Linked list is not an object. An object could be a closure of the list upon
> the relation predecessor-successor, e.g. a set of linked nodes.

So the closure could be mapped to ... what if not an object?

>> <l>
>>   <it id = "one"           f="two" />
>>   <it id = "two"   b="one" f="three" />
>>   <it id = "three" b="two" />
>> </l>
>
> Which speaks for itself.

Indeed, it shows that you can have the kind of structures you wanted;
I'll gladly add recursive structure � la Ada; for now,

   l'(it'(id => one, f => two, others => <>),
      it'(id => two, f => three, b => one),
      it'(id => three, b => two, others => <>);

Stream this aggregate to a C++ program outside your project ...


>>>>> 6. requires complex, resource consuming, vulnerable infrastructure like
>>>>> parsers
>>>>
>>>> Yes, there are cases where such parsers are needed, and even more
>>>> of such things. For example, if you run Google.
>>>
>>> Remember that the case in question is "exchanging structured data," not
>>> running Google.
>>
>> Google is the biggest thing on earth that exchanges data with
>> just about everything outside microwave ovens.
>
> This is why XML would not require complex, resource consuming, vulnerable
> parsers?

XML will not require complex, resource consuming, vulnerable parsers
once applications need not input non-XML data, such as Excel files
or HTML pages.


>> The purpose of "syntactic excess" of XML is about the same as in Ada:
>
> Not at all. Ada's redundancy is here to reduce influence of certain class
> of programming errors.

For example, Ada has named brackets in place of overloaded brackets
in many places. Like XML.

> Ada is not proposed for exchanging structured data
> between computers.

It is, however, required to say how to exchange structured program
source text between compilers.

> Ada is a programming language. XML in this context plays
> the role of a protocol to exchange above mentioned data.

No. It is a markup language for tagging data in text documents.
We have been here before.

> The nature of
> errors which may appear upon such data exchange, their behavior has close
> to nothing in common to the typo errors programmers do when they write Ada
> code.

When programmers correct errors that the compilers have found,
some of the are strictly syntax errors, others are of a more
grammatical nature. Source text not being a stream of octets
makes correcting Ada source text easier. Similarly for XML.


>>>> You don't have to write parser infrastructure when you
>>>> can use XML.
>>>
>>> 1. I don't need parser if I don't use XML.
>>
>> I need to write many parsers if I can't use XML. I use data not
>> generated by our programs.
>
> In that case this is irrelevant to the issue.

Irrelevant to your issue, I guess, of exchanging data in a network
where all components know what's required to participate. The issues
other people face have to do with mutual, deliberate lack of information,
and with non-coordination. If inscrutable serializing is added on
top of that, parties end up with trial and error. That's a lot less so
when they at least use  XML.


> A protocol similar to one of Ada streams deploy does not need
> parsing.

An exchange of data using streams does not work without agreements
on the stream's content; streams from 'Write are not usually
self-documenting. That's a lot less so with XML, therefore XML
is a suitable choice in situations without agreements.


>>> Safety could be against
>>>
>>> 1. intentional misuse
>>
>> I don't see how any source of data could protect against misuse of data
>> once data have left the "building".
>
> http://en.wikipedia.org/wiki/Digital_signature

Party A   1 <----> *   Party B

Party A provides data together with a signature.
The signature says that what was sent was really sent by A.
How does a signature prevent misusing what was sent?
(How can a signed kitchen knife prevent its use as a weapon?)
The recipient does not learn anything except that the origin is A.
The recipient cannot validate the structure using a signature.
The recipient is free to use information in ways not foreseen.

No accessible piece of data in whichever shape of form can
be protected from being used in any way.

Being able to interpret data is a consequence of assigning
meaning to its parts. A and B may have differing views on that.

There are networks without an arbiter. Then, if things work for
both A and B, then they are both right.


>>> 2. unintentional errors
>>
>> ?
>
> E.g. typo errors. Baiting, when you type some garbage to let the compiler
> to make a suggestion etc.

XML does not only provide for error recovery, as do other ways of
exchanging data. (E.g. through bracket naming, or through a
redundant amount of syntax; some markup is redundant in that an
SGML/XML processor could infer it without running into ambiguity).
It can also have good effects on producers of XML insofar as they can
employ ubiquitous tools to make sure they are really producing
XML documents.

Many do.