Java has XML-parsing libraries aplenty. So why not use XML?
For medical reasons.
Even Apple has said, essentially, "don't use the old format if you
don't have to".
And?
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?
(1) because I wrote it for my specific needs
(2) it's open source... feel free to tailor it to your needs if you are
so inclined
Since property lists are text files, *everything* is converted to
String.
Are you saying that you have no equivalent to NSData?
Yes, considering how trivial it's to encode binary data into whatever
format you see fit. Plus there is no real equivalent to NSData in Java.
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?
While not the purpose of this endeavor, you can store arbitrary objects
as long as their string representation is meaningful.
| - Mandatory quotation marks around java.lang.String
If you're going to call your files "plist format",
I'm not. It's my own little concoction. Simply giving credit where
credit is due.
On the other hand, Apple's NSPropertyListSerialization is quite happy
to handle all this as I'm producing a subset of the original format.
Try to open the generate example file with the Property List Editor to
see what I mean.
you should probably accept anything that's a valid file according to
Apple's specs, which means accepting strings without quotes.
Unnecessary complication.
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.
Contributions warmly welcome!
So how would anObject be stored?
Depending on its type.
As a Collection, a Map, or a String?
One of those.
And how does the original object's class get discovered when the
stored data is reread?
It doesn't.
To reiterate:
"In contrast to archiving (see the NSArchiver class specification), the
serialization process preserves only structural information, not class
information. If a property list is serialized and then deserialized,
the objects in the resulting property list might not be of the same
class as the objects in the original property list. However, the
structure and interrelationships of the data in the resulting property
list are identical to that in the original..."
"Plist format" files have no provision for such information.
Very true. And it's not the purpose of this exercise. Even though
adding type information would be quite trivial. But then again this is
not the point of this particular serialization process.
If you would like to preserve type information and don't mind angle
brackets, you might be interested by XStream:
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.
Hmmm... you totally lost me here... what are you talking about exactly?
Are you not confusing java.util.Properties and what java.util.pref
does? Clarifications welcome.
What advantages does your library offer that the Java classes don't?
To the universe at large? I don't know. To me? Enough benefits to
account for my time.
Why would I want to use your (non-standard) library rather than the
(standard) java.util.Properties classes?
You? Glen Fisher? How would I know. If you are happy with
java.util.Properties then by all measures stick with it.
What you describe doesn't look better, only different.
Then "Vive La Difference"!
Along those lines, perhaps I could interest you in YAML:
_______________________________________________
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
