text.Properties interface should be consistent

schveiguy Joined: 08/02/07 Posts: 128

Posted: 10/29/07 17:30:32 Looking at the current interface for text.Properties, the load functions use a delegate to process the properties in the stream. The save functions use an associative array which contains all the properties as a parameter. I think the interface should be consistent for saving and loading. If I am storing properties in some way other than an associative array, I should not have to first convert to the AA before storing. Perhaps some sort of container interface? Like: interface PropertyContainer(T) { void add(T[] name, T[] value); int opApply(delegate dg(ref T[] name, ref T[] value)); } Then the Properties class would use a PropertyContainer? class to interface between the runtime storage method chosen by the coder and a file/stream. The interface would be consistent with both saving and loading. Then, you would probably want a default PropertyContainer? that stored its properties as an AA. I can code up something like this if it's something that people want. -Steve

Author	Message
kris Joined: 03/27/04 Posts: 581	Posted: 10/29/07 18:54:36 Sure, that sounds good !
schveiguy Joined: 08/02/07 Posts: 128	Posted: 10/29/07 19:35:20 Did it. Should I post the code to a ticket? BTW, I realized that the PropertyContainer? interface is a subset of the tango.util.collection.Map interface, so I just used Map instead of adding a new interface. -Steve
kris Joined: 03/27/04 Posts: 581	Posted: 10/29/07 19:46:59 A ticket is a good way to attach code. Also, I'm not sure if it's a good idea to couple Properties directly to tango.util.collection
schveiguy Joined: 08/02/07 Posts: 128	Posted: 10/29/07 20:24:59 -- Modified: 10/29/07 21:21:04 by schveiguy -- Modified 2 Times OK, I'll make a ticket Re: using tango.util.collection.Map as the interface, I also thought it might not be an acceptable idea. It would be nice if there was a dependency tree of packages somewhere so one can know which packages depend on other ones. This would allow someone contributing code to know which packages are usable from which other packages. The benefit to using Map as the interface is that one can use any container that implements the Map interface. There are currently several to choose from. The drawback I see (aside from making tango.text depend on tango.util.collection) is if you want to write your own property container object, you have to implement all the interface of Map. I'll change it so it does not use tango.util.collection and post my code in a ticket. (Ticket made, #713) -Steve
kris Joined: 03/27/04 Posts: 581	Posted: 10/29/07 21:23:51 agreed. If we reduce to a single delegate instead, then we can make the delegate compatible with a Map equivalent. No other dependencies would be required. Thanks for doing this, btw