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 > M +1-234-716-2658 > F +1-330-818-2560 > > email/Skype: jim.ma...@beryle-lee.com <mailto:jim.ma...@beryle-lee.com> > 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 <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 <mailto: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 <mailto: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. >>> 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 >>> (swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
