> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution > <[email protected]> wrote: > > I am firmly against this. The 5 levels that we have cover us well and have > enough complexity already.
Agree. > On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution > <[email protected]> wrote: > I agree that classprivate would probably not work, maybe constructprivate? > but then you are leaving our enum etc. > With the `internal(class)` suggestion, if declaring a var such as > `internal(set) var name: String?` would this become `internal(class, set) var > name: String?` > Also there would need to be some kind of compile check either way because if > you declared an enum for example outside of a constructor you would not be > able to mark it as our new constructor only access level or it would become > inaccessible throughout the project. > > Re: submodules, they are indeed overkill for this. As you would need a > separate submodule for each class you wanted to do this with and then run the > risk of inter coupling lots of different really small submodules. > > Suggestions so far: > `classprivate` > `constructprivate` > `private(instance)`, `private(instance, set)` - problem -> how would this > work? `public private(instance, set)` > `internal(class)` > > Personally I think a name like `classprivate` or `constructprivate`, although > not particularly well named would reduce complexities with private setters > syntax and keep migrations much simpler. > > > On Sat, 10 Sep 2016 at 07:09 Adrian Zubarev via swift-evolution > <[email protected]> wrote: > I don't think submodules would solve it nicely. Each module/submodule will > require it's own namespace + it feels like an overkill to create submodules > for a few types. `internal(xyz)` seems to me like a better solution. And yes > this is purely additional and nothing for phase 1. > > -- > Adrian Zubarev > Sent with Airmail > Am 9. September 2016 um 19:09:12, Xiaodi Wu ([email protected]) schrieb: > >> Isn't the general solution to this problem submodules? In any case, seems >> like it'd be out of scope for Swift 4 phase 1. >> >> >> On Fri, Sep 9, 2016 at 11:34 AM, Adrian Zubarev via swift-evolution >> <[email protected]> wrote: >> There must be a better solution to this problem, because you might also >> extend value types from different files. That would mean, we'd need >> `structprivate` `protocolprivate` etc. >> >> How about: `internal(class)` etc. ? Or something like `internal(private)` to >> rule them all (I don't like the last name, but something that would rule >> them all would be nice to have)! >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> Am 9. September 2016 um 17:49:29, Tom Bates via swift-evolution >> ([email protected]) schrieb: >> >>> There is currently no way of accessing "shared code" from extensions >>> declared outside the base .swift file >>> >>> I would love to see along side the new fileprivate access level a >>> classprivate access level that would allow any extension declared outside >>> of the original .swift file to access these properties and functions in an >>> attempt to reuse code. >>> >>> an example is below... >>> >>> ================= >>> //MyClass.swift >>> public class MyClass { >>> >>> classprivate func sharedFunction() { >>> self.function1() >>> self.function2() >>> } >>> >>> fileprivate func function1() {} >>> fileprivate func function2() {} >>> } >>> ================= >>> >>> ================= >>> //MyClass+Save.swift >>> extension MyClass { >>> >>> public func save() { >>> self.someFunction() >>> self.sharedFunction() >>> } >>> >>> fileprivate func someFunction() {} >>> } >>> ================= >>> >>> Currently to achieve anything like this you would have to make the "core" >>> functions public or internal or write the whole thing in a single file >>> which as I understand it is not optimal for the compile speed and can get >>> unmanageable for large classes. This would allow a more managed file >>> structure and the separation of related functions from the core declaration. >>> >>> There would be no migration needed I don't think as the impact on current >>> code would be zero until the developer adopts the new access level >>> >>> Regards, >>> Tom >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
