-1 from me. On Thu, Dec 8, 2016 at 7:39 AM, Jim Malak via swift-evolution < swift-evolution@swift.org> wrote:
> Ok, thanks > > - Jim > ------------------------------ > *From:* Adrian Zubarev <adrian.zuba...@devandartist.com> > *Sent:* Thursday, December 8, 2016 7:38:22 AM > *To:* Jim Malak > *Cc:* swift-evolution@swift.org > > *Subject:* Re: [swift-evolution] Any consideration for directoryprivate > as a compliment to fileprivate? > > > 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 (jim.ma...@beryle-lee.com) > 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 <(330)%20818-2600> > M +1-234-716-2658 <(234)%20716-2658> > F +1-330-818-2560 <(330)%20818-2560> > > email/Skype: jim.ma...@beryle-lee.com > http://beryle-lee.com > http://linkedin.com/in/jamesmalak > https://www.facebook.com/BeryleLeeInc > > ------------------------------ > *From:* Aron Lindberg <ar...@me.com> > *Sent:* Thursday, December 8, 2016 7:34:06 AM > *To:* Jim Malak > *Cc:* Adrian Zubarev; swift-evolution@swift.org > *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 < > swift-evolution@swift.org> 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 <(330)%20818-2600> > M +1-234-716-2658 <(234)%20716-2658> > F +1-330-818-2560 <(330)%20818-2560> > > email/Skype: jim.ma...@beryle-lee.com > http://beryle-lee.com > http://linkedin.com/in/jamesmalak > https://www.facebook.com/BeryleLeeInc > > ------------------------------ > *From:* Aron Lindberg <ar...@me.com> > *Sent:* Thursday, December 8, 2016 6:26:10 AM > *To:* Adrian Zubarev > *Cc:* Jim Malak; swift-evolution@swift.org > *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 < > swift-evolution@swift.org> 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 ( > adrian.zuba...@devandartist.com) 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. ty > perprivate, typepublic all these requests for new access modifiers. [image: > facepalm] > > 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 ( > swift-evolution@swift.org) 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution