Re: Standard Library Interest?

["Stephane Richard" <stephane.richard@verizon.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1432352.H7KnUpQB8m@linux1.krischik.com...

> True. But It could be a starting point. You have to start somewhere or
give
> up and return to using C++.
>

I'm affraid I have to agree with Marin David Condic on this one. if we don't
start it the right way we can't expect it to finish the right way either.
Code wise well I'm sure that even if we dont all use the "Ada quality And
Style" standards and suggestions, we all write decent code as in good
variable naming, clear function names, etc etc....so maybe we can used that
code itself, or play with it to make it comply to a given standard.  But
documentation wise, it's a different story.  As Warren said on one of his
messages, a lot of code I've seen to can't even answer the question "Why do
I need this thing?"  Others aren't clear as to how to use it, what are the
pre requesits, and other "what I deem essential" information on the package
and it's contents.

I agree to not reinvent the wheel.  But for the sake of the quality of the
whole library, maybe we can take a chizel and pick at that wheel a little?
:-).  (again another cheap attempt at a metaphore ;-).  The question is
where do we draw the line?  As in sure there's code outthere to sort an
array many different ways, how do we determine that code is bad? Code should
be acceptable provided it has clear names throughout the library for
variables, procedures, functions, package names, task names etc etc....a
minimal source code commenting scheme, and  a minimal documentation (that is
detailed enough so that anyone can read it and use the given library as it
was meant to be used.

What we could do perhaps is in teh revision process take anycode out there
and first see how bad or good it is, see what needs to be added (comment
wise) see what the doc says and conclude of it's viability as a library
component.  I dont know how everyone codes, but those that I do know how
they code, so far, I'd throw their code right in the library with both my
eyes closed :-).  Documentation wise?  Well that can vary from library to
library.   Sure that means more work for bigger packages, but for the sake
of the quality of the whole library, this process should be close to
mandatory.

For documentation it doesn't really need to be a document file, could be a
sample program that is documented comment wise enough to explain the where
and how to's then either the author of the code or anyone that feels like it
really could take that sample program, and form a decent documentation from
it.....what the document should state?  well that we can work on :-)....but
as a basis it should say,
What it is,
How it's organized (a text hierarchy of packages might be quickly done and
clear enough).
Relationships between the parts
Quick listing of procedures and function (as per the spec file).  perhaps
AdaBrowse can do a fine job of that without changes.
How to's (how to use it)
Discrepencies (if any)
Pre-requisites to using the library...as such
    - Which OS it is supposed to work for
    - Which version of the OS and the Compiler

basically. :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com