Any consideration for directoryprivate as a compliment to fileprivate?

Evolution Discussion
1

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

2

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) 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

3

I guess it's just coincidence, but this thread about "directoryprivate" did start while the thread about "typeprivate" (which ended up as a general discussion) is fading away without real results…

To me, this looks like an indication for two* things:

a) Access levels are broken** in Swift 3

b) The tool used for discussion (mailing list) is broken** as well

Right now, I'm in the mood to write a rant about b) (that might change until I have time to do so ;-), but returning back to topic, I really don't think adding more and more levels with more and more magic words is a bad idea.
Additionally, "directoryprivate" will be really painful due to the way Xcode deals with the filesystem (although that might be an argument for adding it, as imho Xcode needs improvement in this aspect anyways ;-)

- Tino

* three things to be honest; but the last one would be to controversial for a half sentence without explanation

** actually, I think "broken" is way to hard — but judging from past experience, I come to the sad conclusion that provoking statements are better to drive discussion ;-)

4

Hi Adrian,

Yes, submodule would describe it.

- Jim

···

_____________________________
From: Adrian Zubarev <adrian.zubarev@devandartist.com<mailto:adrian.zubarev@devandartist.com>>
Sent: Thursday, December 8, 2016 2:18 AM
Subject: Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?
To: Jim Malak <jim.malak@beryle-lee.com<mailto:jim.malak@beryle-lee.com>>
Cc: <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>

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.[facepalm]

Instead of just going with

privateprivate(file)// for new one private(type)

I know there would be some people that would forget about (file/type) and write onlyprivate 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 ofsubmodules. :) 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

5

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@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) 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

6

Hi Tino,
This is my first use of this forum. I certainly did not mean to cause pain for anyone.
At Gonzalo's invitation I have looked over the thread for his proposal and I am withdrawing my request and backing his with a very heavy +1.
The group has done an amazing job with the open source development of Swift. Though this email approach may cause some problems, all of you have advanced the language tremendously in a very short period of time.
If I have offended anyone I ask their forgiveness. Since you mentioned it I will state that the Xcode approach to project groups is one that I have yet to understand the merit of.
Gonzalo: please let me know how I can assist you.
- Jim

···

_____________________________
From: Tino Heth <2th@gmx.de<mailto:2th@gmx.de>>
Sent: Thursday, December 8, 2016 12:08 PM
Subject: Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?
To: Jim Malak <jim.malak@beryle-lee.com<mailto:jim.malak@beryle-lee.com>>
Cc: <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>

I guess it's just coincidence, but this thread about "directoryprivate" did start while the thread about "typeprivate" (which ended up as a general discussion) is fading away without real results...

To me, this looks like an indication for two* things:

a) Access levels are broken** in Swift 3

b) The tool used for discussion (mailing list) is broken** as well

Right now, I'm in the mood to write a rant about b) (that might change until I have time to do so ;-), but returning back to topic, I really don't think adding more and more levels with more and more magic words is a bad idea.
Additionally, "directoryprivate" will be really painful due to the way Xcode deals with the filesystem (although that might be an argument for adding it, as imho Xcode needs improvement in this aspect anyways ;-)

- Tino

* three things to be honest; but the last one would be to controversial for a half sentence without explanation

** actually, I think "broken" is way to hard - but judging from past experience, I come to the sad conclusion that provoking statements are better to drive discussion ;-)

7

-1 we don't need any more access modifiers. We already have an excessive
amount: 5

···

On Thu, Dec 8, 2016 at 12:55 PM Jim Malak via swift-evolution < swift-evolution@swift.org> wrote:

Hi Tino,
This is my first use of this forum. I certainly did not mean to cause pain
for anyone.
At Gonzalo's invitation I have looked over the thread for his proposal and
I am withdrawing my request and backing his with a very heavy +1.
The group has done an amazing job with the open source development of
Swift. Though this email approach may cause some problems, all of you have
advanced the language tremendously in a very short period of time.
If I have offended anyone I ask their forgiveness. Since you mentioned it
I will state that the Xcode approach to project groups is one that I have
yet to understand the merit of.
Gonzalo: please let me know how I can assist you.
- Jim

_____________________________
From: Tino Heth <2th@gmx.de>
Sent: Thursday, December 8, 2016 12:08 PM

Subject: Re: [swift-evolution] Any consideration for directoryprivate as a
compliment to fileprivate?
To: Jim Malak <jim.malak@beryle-lee.com>
Cc: <swift-evolution@swift.org>

I guess it's just coincidence, but this thread about "directoryprivate"
did start while the thread about "typeprivate" (which ended up as a general
discussion) is fading away without real results…

To me, this looks like an indication for two* things:

a) Access levels are broken** in Swift 3

b) The tool used for discussion (mailing list) is broken** as well

Right now, I'm in the mood to write a rant about b) (that might change
until I have time to do so ;-), but returning back to topic, I really don't
think adding more and more levels with more and more magic words is a bad
idea.
Additionally, "directoryprivate" will be really painful due to the way
Xcode deals with the filesystem (although that might be an argument for
adding it, as imho Xcode needs improvement in this aspect anyways ;-)

- Tino

* three things to be honest; but the last one would be to controversial
for a half sentence without explanation

** actually, I think "broken" is way to hard — but judging from past
experience, I come to the sad conclusion that provoking statements are
better to drive discussion ;-)

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

Hi Jim,

This is my first use of this forum. I certainly did not mean to cause pain for anyone.

I hope I didn't sound as if I was blaming you — imho it is not realistic to keep track of the evolution process as it is organised now, so even exact repetition is rather common

At Gonzalo's invitation I have looked over the thread for his proposal and I am withdrawing my request and backing his with a very heavy +1.

This one? https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

If I have offended anyone I ask their forgiveness. Since you mentioned it I will state that the Xcode approach to project groups is one that I have yet to understand the merit of.
Gonzalo: please let me know how I can assist you.

I don't think anyone is offended, and imho your offer to Gonzalo is a good move (it's just sad that there is no established tool for such collaboration)

9

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.zubarev@devandartist.com <mailto:adrian.zubarev@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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

@Jim

You most certainly offended no one! Quite the opposite. This being an open
source community, every contribution counts and, imho, you did nothing but
to *contribute *to swift's evolution!

Thanks for backing typeprivate proposal. We have been looking for ways to
restructure our proposal based on all the fine arguments raised by everyone
during the discussion, however we have not found time to complete it. We
will definitely keep in touch in the following days. I believe your
proposal really relates to ours. The real urge is to revisit access level
controls, if need it be, and create finer grained modifiers for better
communication.

@Derrick

This being said, the solution might even reduce the number of access
control modifiers and not just add one more to the pile. I think we all aim
to have the right amount of modifiers for the right amount of use cases.
Should they be organised and designed in a way that better conveys their
intent, then I believe the number will not be the number one problem.

@Tino

I do agree with you. It is sometimes hard to keep track of all the
proposals/discussions being raised. While I do believe this is an open
enough forum for everyone to participate in, it can become quite hard to
have the full spectrum of discussions in sight at first glance.

Best,
Gonçalo

···

2016-12-08 18:51 GMT+00:00 Tino Heth <2th@gmx.de>:

Hi Jim,

> This is my first use of this forum. I certainly did not mean to cause
pain for anyone.

I hope I didn't sound as if I was blaming you — imho it is not realistic
to keep track of the evolution process as it is organised now, so even
exact repetition is rather common

> At Gonzalo's invitation I have looked over the thread for his proposal
and I am withdrawing my request and backing his with a very heavy +1.
This one? GitHub - goncaloalvarez/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/NNNN-introduce-typeprivate-access-control-level.md

> If I have offended anyone I ask their forgiveness. Since you mentioned
it I will state that the Xcode approach to project groups is one that I
have yet to understand the merit of.
> Gonzalo: please let me know how I can assist you.
I don't think anyone is offended, and imho your offer to Gonzalo is a good
move (it's just sad that there is no established tool for such
collaboration)

11

-1 will just bring mess and unclearness.

It can work with Java-like approach where a package is a folder. Since we
have no strict decisions for that - please, don't do it.

···

On Thu, 8 Dec 2016 at 21:10 Gonçalo Alvarez Peixoto via swift-evolution < swift-evolution@swift.org> wrote:

@Jim

You most certainly offended no one! Quite the opposite. This being an open
source community, every contribution counts and, imho, you did nothing but
to *contribute *to swift's evolution!

Thanks for backing typeprivate proposal. We have been looking for ways to
restructure our proposal based on all the fine arguments raised by everyone
during the discussion, however we have not found time to complete it. We
will definitely keep in touch in the following days. I believe your
proposal really relates to ours. The real urge is to revisit access level
controls, if need it be, and create finer grained modifiers for better
communication.

@Derrick

This being said, the solution might even reduce the number of access
control modifiers and not just add one more to the pile. I think we all aim
to have the right amount of modifiers for the right amount of use cases.
Should they be organised and designed in a way that better conveys their
intent, then I believe the number will not be the number one problem.

@Tino

I do agree with you. It is sometimes hard to keep track of all the
proposals/discussions being raised. While I do believe this is an open
enough forum for everyone to participate in, it can become quite hard to
have the full spectrum of discussions in sight at first glance.

Best,
Gonçalo

2016-12-08 18:51 GMT+00:00 Tino Heth <2th@gmx.de>:

Hi Jim,

> This is my first use of this forum. I certainly did not mean to cause
pain for anyone.

I hope I didn't sound as if I was blaming you — imho it is not realistic
to keep track of the evolution process as it is organised now, so even
exact repetition is rather common

> At Gonzalo's invitation I have looked over the thread for his proposal
and I am withdrawing my request and backing his with a very heavy +1.

This one?
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

> If I have offended anyone I ask their forgiveness. Since you mentioned
it I will state that the Xcode approach to project groups is one that I
have yet to understand the merit of.

> Gonzalo: please let me know how I can assist you.

I don't think anyone is offended, and imho your offer to Gonzalo is a good
move (it's just sad that there is no established tool for such
collaboration)

_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

12

Personal statement: –1

···

--
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (aronl@me.com) 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 <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.zubarev@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) 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

13

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.malak@beryle-lee.com<mailto:jim.malak@beryle-lee.com>

http://linkedin.com/in/jamesmalak

···

________________________________
From: Aron Lindberg <aronl@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.zubarev@devandartist.com<mailto:adrian.zubarev@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. [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<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

14

Will discprivate be next? and then systemprivate? </facetious>

-1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Swiftrien (Rien) · GitHub
Project: http://swiftfire.nl

···

On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Personal statement: –1

--
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (aronl@me.com) 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 <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.zubarev@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) 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

15

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.malak@beryle-lee.com <mailto:jim.malak@beryle-lee.com>
http://beryle-lee.com <http://beryle-lee.com/&gt;
http://linkedin.com/in/jamesmalak
Beryle & Lee, Inc.
From: Aron Lindberg <aronl@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.zubarev@devandartist.com <mailto:adrian.zubarev@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

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: jim.malak@beryle-lee.com<mailto:jim.malak@beryle-lee.com>

http://linkedin.com/in/jamesmalak

···

________________________________
From: Aron Lindberg <aronl@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<mailto: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.malak@beryle-lee.com<mailto:jim.malak@beryle-lee.com>
http://beryle-lee.com<http://beryle-lee.com/&gt;
http://linkedin.com/in/jamesmalak
Redirecting...

________________________________
From: Aron Lindberg <aronl@me.com<mailto:aronl@me.com>>
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org<mailto: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.zubarev@devandartist.com<mailto:adrian.zubarev@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. [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<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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

17

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@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
M +1-234-716-2658
F +1-330-818-2560

email/Skype: jim.malak@beryle-lee.com

http://linkedin.com/in/jamesmalak

From: Aron Lindberg <aronl@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
M +1-234-716-2658
F +1-330-818-2560

email/Skype: jim.malak@beryle-lee.com

http://linkedin.com/in/jamesmalak

From: Aron Lindberg <aronl@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.zubarev@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) 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

18

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 <swift-evolution@swift.org> wrote:

Will discprivate be next? and then systemprivate? </facetious>

-1

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Swiftrien (Rien) · GitHub
Project: http://swiftfire.nl

On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Personal statement: –1

--
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 12:26:17, Aron Lindberg (aronl@me.com) 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 <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.zubarev@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) 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

19

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 <swift-evolution@swift.org> 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 (jim.malak@beryle-lee.com <mailto:jim.malak@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
M +1-234-716-2658
F +1-330-818-2560

email/Skype: jim.malak@beryle-lee.com <mailto:jim.malak@beryle-lee.com>
http://beryle-lee.com <http://beryle-lee.com/&gt;
http://linkedin.com/in/jamesmalak
Beryle & Lee, Inc.
From: Aron Lindberg <aronl@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 <mailto: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.malak@beryle-lee.com <mailto:jim.malak@beryle-lee.com>
http://beryle-lee.com <http://beryle-lee.com/&gt;
http://linkedin.com/in/jamesmalak
Beryle & Lee, Inc.
From: Aron Lindberg <aronl@me.com <mailto:aronl@me.com>>
Sent: Thursday, December 8, 2016 6:26:10 AM
To: Adrian Zubarev
Cc: Jim Malak; swift-evolution@swift.org <mailto: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.zubarev@devandartist.com <mailto:adrian.zubarev@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

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

20

-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.zubarev@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.malak@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@beryle-lee.com
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
Beryle & Lee, Inc.

------------------------------
*From:* Aron Lindberg <aronl@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.malak@beryle-lee.com
http://beryle-lee.com
http://linkedin.com/in/jamesmalak
Beryle & Lee, Inc.

------------------------------
*From:* Aron Lindberg <aronl@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.zubarev@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