Re: A standard package for config files is needed

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Well, my understanding of the original post was that it was a hypothetical
"Hey! Ada programs have to initialize themselves, so why don't we build
something to interpret initialization files or something similar to the
registry???" Not that it had to duplicate exactly what the registry does -
although there may be those who would want that.

So if you've got a general "Initialization" need - why could you not use
Maps? You look up something based on a key. The "something" could be a
string or it could be a record or whatever seemed to make sense for the
actual implementation. Decide what requirements need to be satisfied then
build the structure to suit that. If you want a tree-like structure, it
might be viewed as a Map of Maps. My idea was that if you had Maps
implemented, you could build a registry-like structure out of it as a basic
building block & end up with another useful component for Grace.

If we had a "Registry" (I use the term in the loose sense) package that was
built from Maps, it might make sense to build a "Registry Editing" package -
although this gets you into having to think about what sort of user
interface you want to support. It could suck it up and spit it out to a text
file, but I'm not sure I'd need that sort of behavior so long as my program
could set configuration information and then retrieve it next time it
started up. (Streams might be good enough for me.) I could see how others
would likely disagree, so I wouldn't consider it a hard requirement - but
then you get into arguing about what sort of format it should have. XML has
advantages in terms of it being able to get infinitely complex as needed,
but then you need a DOM as well as something to interpret it as a
"Registry".

Just a thought as to how to make Grace be more useful.....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205291059.737616ec@posting.google.com...
>
> If you were to use a Grace-style map, I think you'd have to view every
> value as a string (most likely, an Ada.Strings.Unbounded_String). His
> example showed numbers, which presumably folks would want to
> manipulate as numbers, not strings. Then again, Ada's 'value makes it
> pretty easy to do the transformation. However, the user would have to
> handle any errors due to the value being the wrong type.
>
> Its tough to tell from nothing more than an uncommented example, but
> it looked like there was a wee bit more structure to it than just a
> bunch of attribute/value pairs. If that's the case, Maps could
> probably not be used, and a special structure might be required. It
> would be nice to know how much structure there really should be, and
> what it could be.
>
> The way the NT registry works, Keys are stored in a hierarchy (think
> of them as directories), and each one may have multiple "values". A
> value has 3 attributes, its name, its *type*, and its actual value.
> There are lots of different possible types, but in general they are
> all a pain to deal with. :-)  Most folks just stick to the string or
> string array types.
>
> > Assuming we get a Grace component to do this, it might even make a nice
> > extension to the Grace library - a descendent of Maps that handles
>
> If we are talking of it as a standard Ada thing, then I agree.