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

["Vasiliy Molostov" <molostoff@gmail.com>]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug 2012  
04:50:14 +0400:

> On Tuesday, August 14, 2012 5:59:47 PM UTC-6, Vasiliy Molostov wrote:
>> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug  
>> 2012

> Which are routinely subverted by those that break out regex as their  
> "parser" of choice. Further it is a horrible format for random-access,  
> as Randy pointed out, requiring a read-through (parsing) for anything;

For a developer it is a matter of one index file to parse it only once, if  
this is a problem.

> even if you know exactly *where* in your tree-structure it is. {By being  
> in text-format you lose a *lot* of desirable properties.}

Which ones? EOF delimiters?

> This is what makes it unsuitable for many data-intensive applications.

All the web for today works on top of xml, btw. it is very data-intensive.

> I had the chance to work with Combat XXI a few years back --absolutely  
> HUGE Java-program; so much so that ANT couldn't auto-compile it in one  
> go and I needed to write a utility to generate sub-make instructions  
> iterating over the subdirectory tree, leaves-to-root, to ensure that  
> everything compile-- as I was talking to one of the other devs they  
> mentioned that they had to write a binary-equivalent of XML for saving  
> the simulation...

Perhaps you are a second man complaining about broken ant builder, one of  
my friends also had similar problem indeed. Keeping such a binary for only  
one ant tool and loose all other constructive and profitable things is  
possibly a short-sighted solution, where indeed it is an internal ant  
problem.

> because saving as text made the load too slow, and the text bloated the  
> file-sizes to unacceptable levels.

...and depends on structure and content, at first.

> So, even where I concede that XML may be useful (storing objects and  
> their states) it has shortcomings. {Some parsers require keeping the XML  
> structure in-memory; this creates a similar problem as Combat XXI's  
> run-saving, but becomes a problem much earlier: most computers don't  
> have a dozen GB to throw around at a problem.}

xml is a stream oriented format, at first. Perhaps some not good  
implementation
should not revert an opinion on technology by itself. Badly programmed Ada  
package
can not express (invoke a claim) that Ada is bad itself for a whole.

> Given the above [counter-]example, I believe that I have at least given  
> enough evidence to cause one to rethink that statement. A compiler needs  
> a lot of information, true; but that doesn't mean that such information  
> should be bloated by its transport-layer

Transport? Why transport? Interchange layer.

> -- that would be like applying multiple analog-to-digital and  
> digital-to-analog conversions in audio systems: doing a lot of work for  
> nothing, that A-to-D step should happen only once, and [some of] the  
> most hardcore audiophiles will invest in things on the analog side of  
> the switch, which is why you can find amplifiers using vacuum-tubes.)

Interesting paragraph, but it does not relate to xml, xmi, uml or another  
development tool.
Perhaps you can get an example of use xml in ODT/ODF file format  
(previously binary) developed by
OASIS and widely used in MS/Libre world in packages like Openoffice, and  
even is a nation wide standard for now. I found it fast, accessible by
handy tools like scripting, like access from an ada application using  
xmlada or any other xml reader.

Another good example is a docbook format widely used in publishing  
industry. Even Dmitry A. Kazakov usually configures his hardware devices  
with xml based configurations (only imagine - xml parser in a device !!!  
:-O, lol how many things we can discover today ), to say more, at most all  
of ISP provider routers are controlled and configured over IGD protocol  
which is a subset of xml (indeed a wsdl). So perhaps a wind of changes  
already has gone, much time ago. We have xml based world here (on a  
development host).

And surprisingly, a copy conversion from one format to another gives no  
degraded quality - check it with google docs.

I think that a compilation result is not only a set of object files but  
also an automated report (standalone document) where all
actions undertaken and dependencies resolved by the compiler are simply  
described, so a typical customer (or even a compiler itself) can dig it  
and find data from it useful for his own tool/purpose.

The first and most useful thing here is an automated test generation, i  
suppose, and not a "project management".

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/