[swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Thu Dec 8 06:49:07 CST 2016

-1 from me.

On Thu, Dec 8, 2016 at 7:39 AM, Jim Malak via swift-evolution <
swift-evolution at swift.org> wrote:

> Ok, thanks
>
> - Jim
> ------------------------------
> *From:* Adrian Zubarev <adrian.zubarev at devandartist.com>
> *Sent:* Thursday, December 8, 2016 7:38:22 AM
> *To:* Jim Malak
> *Cc:* swift-evolution at 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.malak at 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.malak at beryle-lee.com
> http://beryle-lee.com
> http://linkedin.com/in/jamesmalak
> https://www.facebook.com/BeryleLeeInc
>
> ------------------------------
> *From:* Aron Lindberg <aronl at me.com>
> *Sent:* Thursday, December 8, 2016 7:34:06 AM
> *To:* Jim Malak
> *Cc:* Adrian Zubarev; swift-evolution at 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 at 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.malak at beryle-lee.com
> http://beryle-lee.com
> http://linkedin.com/in/jamesmalak
> https://www.facebook.com/BeryleLeeInc
>
> ------------------------------
> *From:* Aron Lindberg <aronl at me.com>
> *Sent:* Thursday, December 8, 2016 6:26:10 AM
> *To:* Adrian Zubarev
> *Cc:* Jim Malak; swift-evolution at 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 at 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.zubarev at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161208/9d6cc015/attachment.html>