Re: Fwd: Re: [pclasses-devel] P::Classes experimental code

[stephan b. <st...@s1...>]

On Friday 24 December 2004 10:29, Marc Duerner wrote:
> Prefs is an API for loading saving/loading application preferences as
> well as for all sorts of config files. The important thing is that it
> doesnt build on simple string maps but on concrete Entry and Section
> types. So when you change someting in the Prefs and forget to change
> it in your program you are more likely to realise it at compile time.
>

If Entry and Section are made Serializable (automatically the case if 
they are i/ostreamable) then serialzing a Prefs is as simple as 
serializing a map.

Let's take a look...

> class Section {
...
> template <class ValueT>
> class ValueEntry : public Entry {
...
> The Prefs class holds the root section and a PrefsStore class which
> knows how to load and save the data. This would be where I have to
> look at s11n.

So far i see absolutely no problem with s11n compatibility here. Your 
ValueType holds one key element: lexical castability. When a type has 
that it is simpler to serialize, because we can internally simply treat 
it as a string.

> @Stephan what would you suggest? wrapping up s11n in IniStore,
> XmlStore etc? Or kick out PrefsStore and use s11n? It would also be
> interesting to have the parsers as seperate classes in P2.

i would first suggest writing an s11n proxy for the Prefs tree. The only 
thing which might need to change in Prefs (don't yet know) is adding 
some accessors so that s11n can get/set all of the internal data.
i will be happy to experiment with this for you. Caveats:

a) P2 isn't at a state where i can build ps11n against it.
b) i will either use ps11n (with P1) or skip the ps11n support for now 
and simply use s11nlite.

The advantage of a proxy is:

a) Your type doesn't know it's a Serializable.
b) We can swap out proxies later without touching Prefs. That said, i 
*may* need to tweak prefs a bit to make it more s11n-friendly. For 
example, types which are not Default Constructable can't yet be handled 
by s11n without some arcane back-end work involving a custom object 
factory for that type.
c) If the code fails miserably, we can through it away without editing 
Prefs. 


> One other idea I had was to have Iterators that stride (hope that is
> the correct term) over one type of entry. 

"stride" is technically correct, but "traverse" or "iterate" would be 
the normal words, i think. :)

> - Impelment ResolvConf derived from Prefs with its store class for
> the resolv.conf config file format with a NameserverEntry class
> derived from i.e. StringEntry
> - Use "stride" iterator for NameserverEntries to print all nameserver
> entries.

One of the few conventions that s11n really enforces on data is that it 
be structurable similarly to a DOM. That doesn't mean the data file HAS 
to be like a DOM, it just means that as long as we can represent it in 
memory as a DOM-like structure, s11n can work with it.

> The "stride" or "select" iterator was rather easy to implement as a
> template class encapsulating a normal "linear" iterator. operator++
> has to do some type checking though. But maybe that should not be
> part of Prefs but part of the the containers, with SelectTraits or
> something.

That is a good point. i'm a big fan of type traits.

Is the current Prefs interface the one from the P1 CVS tree? If so i 
will take a look and let you know what s11n can or cannot do using the 
current structure.

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts