Did someone ask for more feedback? Overall, I'm pretty -1 on this proposal. I never really liked the fileprivate solution of scope being created to match (in my mind not quite related) file system/organizational boundaries of files–but it was the best compromise we could come up with at the time (I’m up for improvements, but I fear that it’s too late to change now). The issue with directoryprivate/folderprivate is that it takes these issues from fileprivate and compounds across many files. With one file it’s easy to figure out what’s going on, but once you have a more than a few than keeping track of access between them becomes a pain.
Saagar Jha > On Dec 8, 2016, at 4:38 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > As an advice, you should first hear out what the community thinks about the > idea, before writing anything, because one person might share your idea. > Others including myself may not like it. Wait for more feedback first. ;) > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 8. Dezember 2016 um 13:35:56, Jim Malak ([email protected] > <mailto:[email protected]>) schrieb: > >> Great. Is there some other steps I should go through or is the next step to >> write a draft proposal? >> >> Kind regards, >> Jim Malak >> Director >> Beryle & Lee, Inc, >> O +1-330-818-2600 >> M +1-234-716-2658 >> F +1-330-818-2560 >> >> email/Skype: [email protected] <mailto:[email protected]> >> http://beryle-lee.com <http://beryle-lee.com/> >> http://linkedin.com/in/jamesmalak <http://linkedin.com/in/jamesmalak> >> https://www.facebook.com/BeryleLeeInc <https://www.facebook.com/BeryleLeeInc> >> From: Aron Lindberg <[email protected]> >> Sent: Thursday, December 8, 2016 7:34:06 AM >> To: Jim Malak >> Cc: Adrian Zubarev; [email protected] >> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a >> compliment to fileprivate? >> >> Since Xcode is not a requirement for Swift development no, I was talking >> about a file system folder. >> >>> On 8 Dec 2016, at 13.30, Jim Malak via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I totally agree. For clarity, are we in agreement that the definition of >>> "folder" is the underlying file system's implementation of a folder rather >>> than some metadata setting? I am thinking of how Xcode as a view of project >>> folder that at times can leave on one confused. >>> >>> My preference is to keep it simple, to use the underlying file system to >>> decide what is a folder. Does that sound ok? >>> >>> Kind regards, >>> Jim Malak >>> Director >>> Beryle & Lee, Inc, >>> O +1-330-818-2600 >>> M +1-234-716-2658 >>> F +1-330-818-2560 >>> >>> email/Skype: [email protected] <mailto:[email protected]> >>> http://beryle-lee.com <http://beryle-lee.com/> >>> http://linkedin.com/in/jamesmalak <http://linkedin.com/in/jamesmalak> >>> https://www.facebook.com/BeryleLeeInc >>> <https://www.facebook.com/BeryleLeeInc> >>> From: Aron Lindberg <[email protected] <mailto:[email protected]>> >>> Sent: Thursday, December 8, 2016 6:26:10 AM >>> To: Adrian Zubarev >>> Cc: Jim Malak; [email protected] <mailto:[email protected]> >>> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a >>> compliment to fileprivate? >>> >>> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[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
