PA wrote:
| <argh>That's it. I had it with java.util.Properties...</argh>
Why? I've used them with no problems. What problems are you running into?
| Uses "plist" serialization format instead of Sun's one:
On the Mac, java.util.Properties *does* use "plist" serialization.
| http://developer.apple.com/documentation/Cocoa/Conceptual/
| PropertyLists/Concepts/OldStylePListsConcept.html
Java has XML-parsing libraries aplenty. So why not use XML? Even Apple has said, essentially, "don't use the old format if you don't have to".
| - Only supports java.util.Collection and java.util.Map
One of the things I detest about the Cocoa "user defaults" is precisely that it can't handle anything but a limited set of types. If you need something of another type, it has to be converted to one of the "allowed" types. (They at least have a "binary data" type to convert to.) As long as you're rolling your own, why not make it easily extensible?
| - Everything else is converted to java.lang.String
Since property lists are text files, *everything* is converted to String. So I don't know what this statement means.
Are you saying that you have no equivalent to NSData? How do you tell a string that encodes an object from a string that's a string? Or is it not possible to store an arbitrary object?
| - Mandatory quotation marks around java.lang.String
If you're going to call your files "plist format", you should probably accept anything that's a valid file according to Apple's specs, which means accepting strings without quotes.
Aside from simplifying the code ever-so-slightly, what does this limitation buy you? CPU cycles are cheap; surely you can spend a few deciding whether to look for a quote or a space to end the string.
| EXAMPLE
|
| Object anObject = SZPropertiesReader.readObject( anInputStream );
|
| SZPropertiesWriter.writeObject( anObject, anOutputStream );
So how would anObject be stored? As a Collection, a Map, or a String? And how does the original object's class get discovered when the stored data is reread? "Plist format" files have no provision for such information.
| // Alternatively
|
| SZProperties someProperties = new SZProperties();
|
| someProperties.load( anInputStream );
| someProperties.store( anOutputStream );
Right here, you lost any interest I might have had. To me, "properties" are a collection of objects which have no inherent connection with one another. I want be able to access any property without even being *aware* that other properties exist. This example code suggests that I must deal with all my properties as a single lump. In addition, with java.util.Properties (and of the Cocoa "user defaults" classes), I don't have to worry about how to store them when I'm not using them. The library takes care of it all, behind the scenes. If I were to write my own "properties" library, I'd make sure to preserve that behavior.
| If you feel adventurous, you can find a compiled jar as well as what
| could be construed as "source code" at the following location:
What advantages does your library offer that the Java classes don't? Why would I want to use your (non-standard) library rather than the (standard) java.util.Properties classes? What you describe doesn't look better, only different.
Glen Fisher
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
