4 ms·

NeXT Plists were a lot like JSON, but OSX Plists were XML (or binary). Apple definitely had their anointed interchange format, and it was not JSON, for several

by quesera 12y ago

NeXT Plists were a lot like JSON, but OSX Plists were XML (or binary). Apple definitely had their anointed interchange format, and it was not JSON, for several reasons -- first among them that Plists predate JavaScript! -- but also because JavaScript types get a bit ambiguous in a ObjC/Cocoa context. Interestingly, Plists can now be XML or JSON (or binary).

__david__ 12y ago
> 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.

by quesera 12y ago

__david__ 12y ago

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