The Death of Cocoa
31–40 of 118 posts
Re: The Death of Cocoa
#32Swift has the potential to become a great systems language but I am cautious it will replace Foundation/AppKit/UIKit. For example, a Swift string IS an NSString (at the moment at least). It's impossible to know for sure, but when you look back 15 years ago when Cocoa was the new and shiny to the old-trusty Carbon. Apple was actually writing software in Cocoa internally. Everything they were building towards extended…
Re: The Death of Cocoa
#33Earlier quoted context omitted.
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).
> 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 - array 1 2 3 4 david great $ sw_vers -productVersion 10.10.1
Re: The Death of Cocoa
#34Earlier quoted context omitted.
> 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 - array 1 2 3 4 david great $ sw_vers -productVersion 10.10.1
Dear Lord in heaven, who can possibly prefer the XML version? That's hideous!
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.
Re: The Death of Cocoa
#35Earlier quoted context omitted.
> 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 - array 1 2 3 4 david great $ sw_vers -productVersion 10.10.1
> Old style text plists are still supported: True. Read-only, however. :) And the type ambiguity is amply demonstrated.
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.
Re: The Death of Cocoa
#36"One of the truly clever design choices for Swift's String is the internal use of encoding-independent Unicode characters, with exposed "views" to specific encodings:
A collection of UTF-8 code units (accessed with the string’s utf8 property)
A collection of UTF-16 code units (accessed with the string’s utf16 property)
A collection of 21-bit Unicode scalar values, equivalent to the string’s UTF-32 encoding form (accessed with the string's unicodeScalars property)"
Re: The Death of Cocoa
#37Earlier quoted context omitted.
> 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.
I will now manipulate ancient Plists with less fear. :-)
Re: The Death of Cocoa
#38I clicked on this link thinking "yeah, hot chocolate has kind of vanquished cocoa hasn't it?" Very disappointing to discover this had nothing to do with chocolatey drinks.
Re: The Death of Cocoa
#39I clicked on this link thinking "yeah, hot chocolate has kind of vanquished cocoa hasn't it?" Very disappointing to discover this had nothing to do with chocolatey drinks.