Re: Feasibility/Requirements/Wishes of xAL (was: 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: 5667 bytes --]

See my comments distributed appropriately in your message.  preceded by  a
***

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
>
> I'll start with some requirements:
>
> - some system for documentation. Something like python or java
> documentation. The kind that you can browse with your browser. I kinda
> like that.

*** AdaDoc, AdaBrowse, alibrowse (this may be the same as adda browse) seem
to be the most used forms of Ada documentor.

>
> - a style guide. The style guide provides rules and guidelines how to
> format your code. Result should be consistent formatting and naming in
> the code.
>
*** On my website (http://www.adaworld.com), in the "related Links" I have a
link to Ada 95 Quality and Style.  Which could serve as the basis for how we
produce code. and probably answers what we need for coding style. or at
least a good start to build our own standards on.

> - reviewers. People who review the code that developers want to be
> included in the library. Because we only want quality code, don't we? The
> question here is: what is quality code and what isn't?

*** that's always good practice.  (the better quality code, the better for
sure).  Who would these people be?  as a first phase, since each library
should have it's own testing unit/program.  I would suggest someone other
than the creator of the unit be there to test it or perhaps post it
somewhere for more than one person to trest it, review it, validate it.  In
my experience, the author of the code is always the worst tester of his
creations because he knows too much about it :-).  it allows him to make a
good test system, but in real world situations the fact that he knows so
well how everything works makes him a bad tester by definition :-).
>
> - using proven code. Reinventing the wheel is time consuming and it
> allows the bugs to introduce themself.

*** Indeed this is a good point.  However since this is a starting project I
wonder if this should be done as per what goes in the lbirary instead of
what's out there right now?  (by that I dont mean to say we never should use
already existing code, not at all....for instance, any code produced by
Stephen Leak I would almost add to the library with my eyes closed
(hehehe....I'll take my 20$ now Stephe ;-)....anything existing can go in,
however some of them (especially the bigger engines) might need more work to
make them acceptable to the decided guidelines and code style, minimum
documentation requirements, etc etc...so yes we shouldn't reinvent the wheel
unless reinventing the wheel is quicker than adjusting the wheel to move
forward (if you know what I mean). small existing bindings and libraries
which are small enough or clear enough code wise can definitaly be used too
but would still need to be reviewed (documentation wise possibly too) to fit
in the quality guidelines and coding styles we choose to make "official".
>
> And some wishes:
>
> - portability. It's nice to run it on many platforms. But please, no
> preprocessing stuff. That's horrible
>
> - CORBA. If all components have a CORBA idl interface, other programming
> languages can use the library too without too much hassle.
>
> - lots of developers. How to lure them?
*** A worm at the end of a hook ??    ;-)     Seriously though....this kind
of project will attract programmers by it's definition alone.  Also if it's
evolving (as in no long dead periods which might unintentionally suggest
that the library is dead).  of course the more the users to begin with the
better chances are that something will be moving in the project.  the
reviewers of code and standards could also product a weekly quick report of
what has been done (simple like what they reviewed, what was accepted and
what wasn't).  so visitors can see the work in progress.  Activity is always
attractive.

>
> What do you think of it? What requirements and/or wishes would you like
> to see to be added?

*** So far so good Ching.

*** We will have standards for coding style and such, like Stephe Leake
sugested we all need to be consistent with our naming conventions are a must
as well.  as in all package that open a file should all have the same name
which we could decide on... Do we Load the file, do we Open the file? and
use the same name throughout All of xAL.  Same thing for displaying on
screen, do we Print to screen, do we Output to screen, do we Display, you
know?  pick one name and stick to it.. First advantage of this, greatly
reduce the learning curve of the whole xAL hierarchy sinc euser will be able
to expect Open or Load (whichever we choose) to open a file from the HD).
so if he knows it for one package, he would know it for whatever 1000s of
packages we'd have....this is a must be in my book.

*** Documentation wise (not what is produced by AdaDoc or AdaBrowse) but for
whatever document used to explain the library we'll need a set of "sections"
that shuold be included to providing a minimum amount of documentation.  to
help users of the library answer questions quickly on how to attach the
library, how to use it (with sample calling examples or something.  enough
information for the average programmer to understand what the library or
binding does and how to use it effectively.  Sure on bigger libraries this
will require more work, but ti's a must to maintain the good quality of the
lbirary.

*** We'll also need a structure to accomodate the library that is also
consistent to all packages.  Directory structure for the library and for
each package too.  to be determined but could have \src for the soruce code,
docs, for documentation\ test for testing units...as an example.


>
> CBL