Overkill or not, grouping files into a folder/group + folderprivate smells exactly like a submodule to me. ;)
The only thing I’m repeating over and over is that we should fix that open mess and allow protocols to have the same open/public access level as classes have. open protocol from module A is allowed to be conformed to from module B public protocol from module A can only be used as an interface in module B -- Adrian Zubarev Sent with Airmail Am 8. Dezember 2016 um 13:52:27, Aron Lindberg ([email protected]) schrieb: I realise the general opinion here seems to be that we don't want any more changes to the access modifiers and I can understand why, but please take a look at the use case below: "fileprivate" is needed for certain things like Equatable since the equatable function might need to know about private properties in a class. Lets say I have two structs: struct A { ... } struct B { ... } Both are rather big so I declare each in a separate file (File A, File B), but I need to implement an equals function between these two structs that need access to private properties in both structs. This leaves me with two options: a) Move the two structs into one file and use fileprivate and implement the equals function here. The result is one long messy file. b) Move the two files into a separate module and use "internal" for the variables I need acces to. This feels like overkill and struct A/B might have dependencies that make this inconvenient. Am I missing a more optimal solution here? My point is there are legit use cases of fileprivate there might lead to one really big file, with several classes. Having a folderprivate access level would be one possible solution to this. > On 8 Dec 2016, at 13.22, Rien via swift-evolution <[email protected]> > wrote: > > Will discprivate be next? and then systemprivate? </facetious> > > -1 > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > > > > >> On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution >> <[email protected]> wrote: >> >> Personal statement: –1 >> >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 8. Dezember 2016 um 12:26:17, Aron Lindberg ([email protected]) schrieb: >> >>> I think this is a great idea! >>> >>> I would prefer calling it folderprivate tho. >>> >>>> On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still >>>> sleepy. >>>> >>>> >>>> >>>> >>>> -- >>>> Adrian Zubarev >>>> Sent with Airmail >>>> >>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev >>>> ([email protected]) schrieb: >>>> >>>>> You haven’t seen this in the list because no one requested >>>>> dictionaryprivate yet. :D >>>>> >>>>> @core-team: See what you have done with >>file<<private thing. >>>>> typerprivate, typepublic all these requests for new access modifiers. >>>>> >>>>> Instead of just going with >>>>> >>>>> private >>>>> private(file) >>>>> >>>>> // for new one >>>>> private(type) >>>>> >>>>> I know there would be some people that would forget about (file/type) and >>>>> write only private everywhere, which is probably the main reason why we >>>>> have fileprivate now. >>>>> >>>>> Anyways let’s be a little more constructive here. >>>>> >>>>> Hi Jim, regarding your request, it feels like this is something that >>>>> falls into the topic of submodules. :) Correct me if I’m wrong here. >>>>> >>>>> >>>>> >>>>> -- >>>>> Adrian Zubarev >>>>> Sent with Airmail >>>>> >>>>> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution >>>>> ([email protected]) schrieb: >>>>> >>>>>> My apologies up front if I am going about this incorrectly. I have been >>>>>> exploring extensions in Swift 3 both as a part of protocol-oriented >>>>>> programming and as a way to encapsulate related code to improve >>>>>> readability and maintainablity of otherwise more complex classes I have >>>>>> designed. I am able to encapsulate methods and calculated properties in >>>>>> extensions and restrict their use to the object type I am extending as >>>>>> long as everything is in one file via fileprivate. >>>>>> >>>>>> I would like to be able to have my class or structure file in a >>>>>> directory that contains my associated extensions (also in separate >>>>>> files) and be able to restrict the access of appropriate properties and >>>>>> methods to that common directory. This would allow the same level >>>>>> encapsulation as fileprivate with the benifit of being able to organize >>>>>> code into sepereate files based on function. >>>>>> >>>>>> I did not see this in the commonly rejected list but am unsure if this >>>>>> is something that is out of scope for 4.0. Is this something I can write >>>>>> up a proposal for? Is there some other approach that I missed that I >>>>>> should be using instead? >>>>>> >>>>>> Kind regards, >>>>>> Jim Malak >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
