6 ms·

> 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 {

> 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

quesera 12y ago
> Old style text plists are still supported: True. Read-only, however. :) And the type ambiguity is amply demonstrated.
- __david__ 12y ago
  > 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.
  - quesera 12y ago
    Well, that's good to know, thank you. I will now manipulate ancient Plists with less fear. :-)
wtbob 12y ago
Dear Lord in heaven, who can possibly prefer the XML version? That's hideous!
- quesera 12y ago
  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.
  - FranOntanaya 12y ago
    > 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.
    - Alphasite_ 12y ago
      And that's why we have list editor.
    - Alphasite_ 12y ago
      And that's why we have plist editor.
  - wtbob 12y ago
    > 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.

quesera 12y ago

> Old style text plists are still supported: True. Read-only, however. :) And the type ambiguity is amply demonstrated.

__david__ 12y ago
> 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.
- quesera 12y ago
  Well, that's good to know, thank you. I will now manipulate ancient Plists with less fear. :-)

wtbob 12y ago

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

quesera 12y ago
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.
- FranOntanaya 12y ago
  > 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.
  - Alphasite_ 12y ago
    And that's why we have list editor.
  - Alphasite_ 12y ago
    And that's why we have plist editor.
- wtbob 12y ago
  > 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.