Hacker News Reader

Comment by __david__ | Hacker News Reader

> NeXT Plists were a lot like JSON, but OSX Plists were XML (or binary).

Old style text plists are still supported:

    $ cat > /tmp/test.plist
    {
        "david" = "great";
        "array" = ( 1,2,3,4 );
    }

    $ plutil  -convert xml1 /tmp/test.plist -o -
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    	<key>array</key>
    	<array>
    		<string>1</string>
    		<string>2</string>
    		<string>3</string>
    		<string>4</string>
    	</array>
    	<key>david</key>
    	<string>great</string>
    </dict>
    </plist>

    $ sw_vers -productVersion
    10.10.1

View on HN

Dear Lord in heaven, who can possibly prefer the XML version? That's hideous!

XML parsers prefer the XML version. :)

Less glibly, humans never have to deal with it. Data is serialized and deserialized, typically in binary format. It exports to XML merely as a convenience.

And critically, XML can be typed properly for all ObjC/Cocoa types (sometimes with characteristic XML awkwardness). That XML is wrongly typed, due to the ambiguous source input. JSON would have similar problems. Correct beats pretty, in this case.

> Less glibly, humans never have to deal with it

As long as it works, unless we categorize programmers debugging XML issues as non-human drones.

And that's why we have list editor.

And that's why we have plist editor.

> XML parsers prefer the XML version.

Well yeah, but an XML parser would also have no problem with '<tag name="p"><chardata><char>T</char><char>h</char><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>n</char><char>a</char><char>n</char><char>e</char><punctuation type="full-stop" display-char="." /></tag>', but that would be completely insane.

> Less glibly, humans never have to deal with it. […] It exports to XML merely as a convenience.

For…humans, no?

> And critically, XML can be typed

It looks like the plist supported types too, although I don't know for certain. At least, the numbers weren't quoted in the plist.

> JSON would have similar problems.

Would it? '"2" !== 2', IIRC.

Of course, my preferred syntax would be:

    (dict (david great) (array (1 2 3 4)))

if one wanted to treat numbers as text and:

    (dict (david great) (array ([int]1 [int]2 [int]3 [int]4)))

if one wanted to indicate that they are ASCII decimal-encoded integers or:

    (dict (david great) (array ([bin-int]|AQ==| [bin-int]|Ag==| [bin-int]|AW==| [bin-int]|BA==|)))

if one wished to use binary encoding using network-transfer order, but I am clearly insane.

Not nearly as insane as whoever came up with that XML abomination, though.

Yes, a plist is defined as containing things of very specific types. See my SO answer [1] for an overview and an attempt at a Swift implementation.

[1] http://stackoverflow.com/a/24051062/20371

> Old style text plists are still supported:

True. Read-only, however. :)

And the type ambiguity is amply demonstrated.

> Read-only, however. :)

Nope! :-) While it's true that plutil doesn't support the format, open the plist in Xcode and edit it and it will save it out in the same old-school format. Editing through the programmatic API will also keep the format.

Well, that's good to know, thank you.

I will now manipulate ancient Plists with less fear. :-)

Reply on news.ycombinator.com