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

["Randy Brukardt" <randy@rrsoftware.com>]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wje1nc1hka8ora@aspire.local...
Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
2012 02:31:22 +0400:
>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds 
>> like pure fantasy to me.)
>
>Yep, like tasking in '80-90. It was a pure fantasy. But useful.

Surely it was a fantasy back then, but it was definitely not useful for 
anything beyond toy programs. Certainly not on PCs. It took until the 
Windows 95 era for CPUs to be powerful enough to justify the headaches that 
it introduced.

One the problems for Janus/Ada is that we designed our tasking system mainly 
so that we could pass validation. There was no attempt at efficiency or 
usability simply because it was a silly thing to use at the time (late 
1980s). So there were some design flaws that have made it hard to adapt to 
more modern systems where tasking actually has value.

>> Maintaining two ways to do the same thing is the ultimate in headaches --
>> you get to fix all bugs twice. For files not intended for use beyond the
>> compilation system, it doesn't make much sense to maintain more than one
>> version. (We don't attempt to keep any sort of compatibility on these 
>> files
>> now between different compiler versions.)
>
>No, as I see it that new thing can be on top of already existing one, and 
>this looks like an extension only, a king of.

Complicated sequential text files (which XML are) cannot be an extension of 
simple random-access binary files -- they're just too different. Besides, 
none of the data you are interested in is in the project file anyway; the 
declaration data is in the SYM files. We already have a simplified text 
version of the SYM files for the debugger (and for our debugging). One could 
imagine trying to make those into XML, but that would mean having to 
separate the debugging and debugger files (XML is not readable enough to use 
for debugging, especially as it is not uncommon for only part of the file to 
be written when there is a consistency problem that causes a crash in 
accessing the symbol table. That would prevent using an XML viewer to look 
at them).

>> One could imagine having tools to extract information from the project 
>> files
>> in some other format, but I doubt that we'd change the format a lot. (And
>> such tools would require customer demand, obviously.)
>
>This is one of the ways to attract more customers and minimize effort for 
>existing ones.
>A file can be just another one, does not matter.

Attempting to "attract customers" with off-the-wall ideas of unknown value 
is a good way to go out of business. (Let me tell you about RR's management 
in the late 1980s. Actually, better leave those stories left untold.) One 
needs existing and/or serious potential customers that need something to 
justify a lot of work. (That customer could be internal of course, which is 
where much of the HTML/HTTP support in Claw came from.)

                               Randy.