4 ms·

The NeXT/Apple ASCII encoding of their PLIST format is very similar to JSON and has been around forever. IIRC TextMate 1 made use of it for much of its bundle s

• 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.
• maxjg 12y ago
  Xcode project files are still saved in this style of plist.