4 ms·
These are small adaptations to Swift's semantics and naming guidelines. There is nothing in these documents that hints at the sort of root and branch redesign o
by fauigerzigerk 11y ago
These are small adaptations to Swift's semantics and naming guidelines. There is nothing in these documents that hints at the sort of root and branch redesign of the APIs that I think is necessary.
Cocoa as a whole is obsolete and needs to be replaced by something better. It is the epitome of everything that is wrong with 1980s/1990s style object oriented design: Huge classes, massive coupling, very little cohesion.
- stevetrewick 11y agoWhile it's true that "the implementation of [all but 3 of] these types will use the existing reference type API", this means (AIUI) that there will now be a swifty shim between swift and Foundation rather than the types being bridged directly. I would expect that would make the job of replacing Foundation with something appropriately modern easier in several dimensions.
- kartickv 11y agoWhat are some examples of "huge classes, massive coupling and very little cohesion"? Barring a few example like NSString UIKit Additions, I thought it's well thought out.
- fauigerzigerk 11y agoOne of the things that permeates the API is a complete lack of separation of data structures and IO. For instance, NSData, NSDictionary and NSArray all have methods for loading and storing their contents from/to a location specified as a URL. NSURL deals with all sorts of stuff like bookmarks, cached resources and file system properties.
- stepanhruda 11y agoE.g. Swift standard library already replaces dictionaries and arrays without adding similar bloat. I think/hope they want feature parity first and then will start moving towards what you propose.
- kartickv 11y agoI see your point. Thanks for explaining.