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 08:53:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: A standard package for config files is needed Date: 01 Jun 2002 11:53:15 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3CF5D7AC.975B0DB3@cs.tu-berlin.de> <4519e058.0205310825.868fe4a@posting.google.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1022947243 4131 128.183.220.71 (1 Jun 2002 16:00:43 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 1 Jun 2002 16:00:43 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:25157 Date: 2002-06-01T16:00:43+00:00 List-Id: "Marin David Condic" writes: > I just don't see file portability being that big an issue. Ok. But others do, so I'm keeping it as a requirement. > Sure, but if the protocol is for the app to establish default values on > startup for anything that is missing and then to save values as user's > change things in the app, it wouldn't be a big deal. That's only one paradigm. I'd like to support as many paradigms as possible, while keeping the implementation simple. > But in an embedded, realtime app, I seldom have Text_IO anyway. :-) Right; this package will be useless in an embedded app. > I'm suggesting that a Stream oriented load/store would get the whole thing > *started* and then these load/store operations could be overriden by child > packages that might support a whole range of different options. Build the > AdaINIRegistry as a tagged record with the right methods that hide the > mechanism for storage and it is easily changed for different situations. That's an idea; I'll have to think about it. > As a matter of fact, the OO strategy would give you the natural > means of doing default initialization of the registry because you > could derive from the root and the "Load" checks to see that > something is present for the app-dependent entries. If not, it > creates them. Hmmm..... another good idea. -- -- Stephe