> On 6 Apr 2017, at 02:54, Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote: > > The developer adds a free function to the file. Or an extension of another > type. Or another type entirely. And they put it in the same file because it > needs to work with the implementation details of the existing type.
This is the part of all of these conversations that concerns me deeply. Is the assumption that it is now “best practice” to place all shared implementation into a single file? Aren’t those files going to become quite large in real world use? That’s a terrible thing to encourage! My experience working with protocol conformances in Objective-C over the years is that breaking protocol conformances into categories/extensions on the original type *in separate files* is the best way to keep things small, testable and focused. Separating protocol conformances into separate files, whilst still being able to access private members of the extended type promotes smaller files, and more focused implementation within those files. I know Swift has different purposes for different people here, but ultimately it’s supposed to support great application development for Apple’s platforms, right? To my eyes, `fileprivate` should never have been introduced without some kind of `typeprivate` (similar to how things would be declared back in Objective-C land with a `*+Private.h` header that you could import when it was needed). Right now, there’s no way to duplicate that pattern in Swift - I would need to make anything I wish to access `internal` which exposes it to everything within the application/module - surprisingly, this is a regression from the tooling and access levels I had available in Objective-C. It feels to me like this is one place where it’d be worth considering what common use case prior to Swift would have been. I understand there are people here who don’t use Xcode, and never will - but the vast majority outside this list *will* use Xcode, and will try to follow established patterns set forth alongside AppKit/UIKit/Foundation. If I end up stuck with what the access levels we have now, it’s a regression on what I could do prior to Swift’s introduction. I would ask that the core team consider the existing use cases by the masses of Cocoa programmers out there before locking this design in for eternity - I hope I’m wrong, but it doesn’t feel like that has happened with the access levels we have in v3 or what’s being proposed for v4. I understand the core team wanting to end this circular, draining conversation, but it also feels to me like having a stable ABI/source is a moot point if known, addressable mistakes are locked into that stability. thanks, Tony ---------- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
