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=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,c78684b2d4add105 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-09 11:29:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny03.gnilink.net.POSTED!53ab2750!not-for-mail From: "Stephane Richard" Newsgroups: comp.lang.ada References: Subject: Re: Feasibility/Requirements/Wishes of xAL (was: Standard Library Interest?) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Thu, 09 Oct 2003 18:29:28 GMT NNTP-Posting-Host: 141.149.81.186 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny03.gnilink.net 1065724168 141.149.81.186 (Thu, 09 Oct 2003 14:29:28 EDT) NNTP-Posting-Date: Thu, 09 Oct 2003 14:29:28 EDT Xref: archiver1.google.com comp.lang.ada:553 Date: 2003-10-09T18:29:28+00:00 List-Id: 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