I am not fully sure all of this was worth it over protected, private, public... we will see ;).
Sent from my iPhone > On 10 Sep 2016, at 13: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. > >> 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
