5 ms·

Foundation is being completely rewritten in Swift in https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation The

Foundation is being completely rewritten in Swift in https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md https://github.com/apple/swift-evolution/blob/master/proposa...

fauigerzigerk 10y 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 10y ago
  While 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 10y ago
  What 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 10y ago
    One 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 10y ago
      E.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 10y ago
      I see your point. Thanks for explaining.

fauigerzigerk 10y 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 10y ago
While 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 10y ago
What 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 10y ago
  One 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 10y ago
    E.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 10y ago
    I see your point. Thanks for explaining.