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

[Shark8 <onewingedshark@gmail.com>]

On Friday, August 10, 2012 4:37:33 PM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012 20:34:24 +0400:
> 
> 
> > On Friday, August 10, 2012 12:00:26 AM UTC-6, Vasiliy Molostov wrote:
> >> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug  
> >> 2012
> >>
> >> > I have mixed feelings about gpr-files.
> >> > It would be interesting to have a DB-based system (or somesuch) where
> >> > the source isn't stored as a simple text-file; though perhaps that  
> >> would
> >> > be a lot of work for little payoff. (The library-system and ALI-files
> >> > could be handled in this manner though.)
> >>
> >> I dont think that placement sources in a db is a portable way, since  
> >> text
> >> is still most
> >> widely used and simple format on all host systems.
> >
> > That's actually pretty irrelevant; given such a system it should be  
> > near-trivial to implement text-file import/export... even iterating over  
> > the project/directory.
> 
> this needs a presence of such a tool and additional database access tools.

Not really, the database access tools would already be there; they would have to be if you were compiling with the system.

> While currently you still need any text editor.

Um, I don't really see the relevance of mentioning a text editor here... so, why?

> So the cost of this solution is higher with less flexibility, you will be  
> obliged
> to accommodate interchange format with client or supplier of such a  
> database to import/export it properly,
> mostly about text import/export properties.

Again, not really; the same way the system would say "we need these objects" is the same way to determine what to export.

> 
> You can try to use tar/tgz files as a database and extend it with desired  
> features,
> and as I see it you will get the same as jar files in java world.

Ew. And that would likely be a horrid idea, updating an object/ALI/source would essentially consist of:
1 - Create a temporary, but properly named file.
2 - Open the archive, adding (w/ replacement/overwrite) the file.
{Incidentally this also would require running the file through the archive's compression.}
3 - Delete the temp-file.

For EVERY change you enact.

> Another  
> good example is a debian source packages -
> very inconvenient for a development (but convenient for distribution), and  
> even requires a special role for that - a package maintainer.

I know nothing about Debian in particular; but I do hate Linux (and Unix) in general. In fact, I think a lot of the blame of "all source-files *must* be plain-text" stems from them. {There's really no reason that source text should be stored as a plain-text for general purpose/use... indeed if it were stored as a structured-file an editor could prevent/warn storing the text if it had syntax errors.}

Yes, plain-text editors are everywhere.... but there's a lot more