Change tango.text.Properties interface to be more consistent

Simple implementation of PropertyMap? interface

Don't use this yet, there is an issue because the add function is not using the dup property of the strings as they are read, so the properties could become corrupted. I will fix the Properties.d file and upload it later.

updated version of Properties.d

OK, safe to use now.

I'm a bit unsure about the change here, since wrapping the native AA type seems to be somewhat redundant? I suspect we can do better than this, and it may help to consider a Stream oriented approach. Experimenting ...

Replying to kris:

I think you might be right. If the PropertyMap? interface is used more as a conversion class instead of both the conversion class AND the final container of the properties, no reimplementation of the AA methods is necessary. To do this, we just get rid of all methods in the PropertyMap? interface except for:

// use this when reading properties from a file
void add(T[] name, T[] value);

// use this when reading properties from memory to write to a file.
int opApply(int delegate(ref T[] name, ref T[] value) dg);

Then SimplePropertyMap? takes an AA reference as an argument to use as a property storage container. Once you are done loading the properties, you use the AA directly, then save them using SimplePropertyMap? again.

Maybe even the Properties class itself could be changed into a filter you attach to a stream. I haven't used the streams interfaces yet, so I'm not sure how that works.

already done and checked-in :)

Thanks, schveiguy

The current version does not address the inconsistency I was thinking of. The inconsistency is in the difference between the second argument of the load/save functions.

static void load (InputStream stream, void delegate (T[] name, T[] value) dg)
...
static void save (OutputStream stream, T[][T[]] properties)
...

Note that the load function allows any method of loading the properties as long as you provide a function to handle them as they arrive, whereas the save method REQUIRES you to store your properties in an associative array before saving.

you're not looking at MapStream? though ... ?

it's perhaps not ideal, but it's pretty close to what you were thinking of? The opApply() is quite useful in this context: http://dsource.org/projects/tango/browser/trunk/tango/io/stream/MapStream.d

Replying to kris:

Yes, this is exactly what I was thinking of. I suppose I expected it to appear in place of Properties.d instead of in a new class:)

Does this not deprecate Properties.d? At least Properties.d should be implemented in terms of MapStream? to make how property files are parsed more maintainable.

Properties.d will be deprecated, probably in the release after this one :)