From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9983e856ed268154 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ChineseT,UTF8 Received: by 10.66.85.8 with SMTP id d8mr2442726paz.40.1344992203069; Tue, 14 Aug 2012 17:56:43 -0700 (PDT) Path: c10ni115103pbw.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Tue, 14 Aug 2012 17:50:14 -0700 (PDT) Organization: http://groups.google.com Message-ID: <9c19af7c-b50a-499f-970f-45f0f6844226@googlegroups.com> References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com> <44bb5c96-a158-41c1-8e7d-ae83b2c0aca1@googlegroups.com> <1552e0d9-7cdf-4075-89d2-9a722c989c8e@googlegroups.com> NNTP-Posting-Host: 69.20.190.126 Mime-Version: 1.0 X-Trace: posting.google.com 1344992202 23058 127.0.0.1 (15 Aug 2012 00:56:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 15 Aug 2012 00:56:42 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: 2012-08-14T17:50:14-07:00 List-Id: On Tuesday, August 14, 2012 5:59:47 PM UTC-6, Vasiliy Molostov wrote: > Shark8 =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0) = =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 = Wed, 15 Aug 2012 =20 > 00:41:06 +0400: >=20 > > On Tuesday, August 14, 2012 9:19:02 AM UTC-6, Vasiliy Molostov wrote: > >> Shark8 =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0= =B0) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC= =D0=B5 Tue, 14 Aug =20 > >> 2012 >=20 > > Oh, I'm not saying it has an unclear purpose. I'm saying that it's a = =20 > > hard format to use nicely, to keep things correct with. Though I do pit= y =20 > > those who have been forced to work projects where regexes are used on = =20 > > XML. (That seems to be a surprisingly common attempt, though it's not = =20 > > possible as it requires something more powerful; the same as between an= =20 > > FSM and PDA, map to those problems, IIRC.) >=20 >=20 > xml is not for human, it is interchange format, e.g. between applications= , =20 > machines, tools etc. > and has nice and rich auto-validation capabilities. Which are routinely subverted by those that break out regex as their "parse= r" of choice. Further it is a horrible format for random-access, as Randy p= ointed out, requiring a read-through (parsing) for anything; even if you kn= ow exactly *where* in your tree-structure it is. {By being in text-format y= ou lose a *lot* of desirable properties.} This is what makes it unsuitable = for many data-intensive applications. I had the chance to work with Combat = XXI a few years back --absolutely HUGE Java-program; so much so that ANT co= uldn't auto-compile it in one go and I needed to write a utility to generat= e sub-make instructions iterating over the subdirectory tree, leaves-to-roo= t, 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... because saving as text made the load too slow, and= the text bloated the file-sizes to unacceptable levels. So, even where I concede that XML may be useful (storing objects and their = states) it has shortcomings. {Some parsers require keeping the XML structur= e 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 th= row around at a problem.} >=20 > > I don't think that's true. (That XML is the best choice for compilers t= o =20 > > use, I mean; I haven't had cause to use ASIS so I can't comment on it.) > it is a reality, and not a matter to trust it's true or not. Given the above [counter-]example, I believe that I have at least given eno= ugh 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 b= e bloated by its transport-layer -- that would be like applying multiple an= alog-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 [so= me of] the most hardcore audiophiles will invest in things on the analog si= de of the switch, which is why you can find amplifiers using vacuum-tubes.)