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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,47bc849aad30d586 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-01 04:23:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!uninett.no!ntnu.no!not-for-mail From: Preben Randhol Newsgroups: comp.lang.ada Subject: Re: A standard package for config files is needed Date: Sat, 1 Jun 2002 11:23:24 +0000 (UTC) Organization: Norwegian university of science and technology Message-ID: References: <3CF6846C.3544EB21@nbi.dk> NNTP-Posting-Host: kiuk0156.chembio.ntnu.no X-Trace: tyfon.itea.ntnu.no 1022930604 4017 129.241.83.82 (1 Jun 2002 11:23:24 GMT) X-Complaints-To: usenet@itea.ntnu.no NNTP-Posting-Date: Sat, 1 Jun 2002 11:23:24 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.ada:25145 Date: 2002-06-01T11:23:24+00:00 List-Id: On Fri, 31 May 2002 09:46:14 -0400, Marin David Condic wrote: > Just to add some useful meat to my own little rant... :-) > > Suppose that we were to get a good spec written for Grace.Maps & have that > up and working. Suppose that we built on top of this some version of Yes, but getting a good spec is far from having a working version :-) Somebody once said: "Development is 25% planning, 75% work (as in implementing++). More planning will lead to that nothing gets done as more and more special cases are found." Of course where the percentage line goes is not important, but there is something like planning yourself to death. We have an expression (there is probably an English equivalent) "One feather became ten hens" :-) > "Grace.AdaINIRegistryWhozits" that implemented some version of a tree-ish, > registry-ish, thingamabob that is built out of Grace.Maps. Provided you've > got your 'Input and 'Output and make a Load and Store operation for the data > structure, you *instantly* have a usable registry/initialization thing. > Programs can use it to set up and retrieve all of their configuration > information and we're off to the races. > > From there, you can start adding child packages: Yes, but if we make the Import_Export_Flat_ASCII_Files parser now we just have to put this as a child package if/when an AdaINIRegistry emerges :-) > But the *real* advantage to this strategy is that you get a usable, real, > component quickly and if you want to provide other capabilities at a later > point, this isn't a problem. Connecting to specific OS capabilities ("The > Registry") could be hidden beneath some additional package. Providing some > sort of mutex capabilities via a database or something could be added on. > Whatever the needs are, you get there eventually. Yes. > > But why agonize over all these details now? We can burn those bridges when > we get to them. :-) Opt for something simple & realizable within our > lifetimes & maybe it will get done. Isn't that keeping within the whole > spirit of "Open Source" and "Bizarre Development" :-) Hehehe Preben