Any consideration for directoryprivate as a compliment to fileprivate?

Jim_Malak · December 8, 2016, 12:39pm

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<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://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/>
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

Jim_Malak · December 8, 2016, 1:09pm

I understand. I am not fixed on this approach ether. I do believe that there needs to be a controllable layer of granularity with respect to what is exposed inside of an extension. I was used this approach since the fileprivate was already there.

I am not looking to make a perceived bad situation worse. I do want to be able have encapsulation in an extension that can be shared in a group that is easy to define and to perceive. Adrian had mentioned an idea that, if I understood it correctly, was based on some modifier to the AC of private.

I can appreciate that what I suggested as a solution may not be well received but I would like to elevate this up to the question of: "Is there support in the community for a way of having properties and methods marked as only accessible between a group of related extensions and the object type that they are extending?"

- Jim

···

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

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<mailto: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/>
http://linkedin.com/in/jamesmalak
Redirecting...

________________________________
From: Aron Lindberg <aronl@me.com<mailto:aronl@me.com>>
Sent: Thursday, December 8, 2016 7:34:06 AM
To: Jim Malak
Cc: Adrian Zubarev; swift-evolution@swift.org<mailto: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/>
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

privateprivate(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

Rien · December 8, 2016, 1:03pm

My standard reply is that when a type implementation gets this big, it is quite possible that the design is sub optimal.

An equate operation between types almost always means that they have something in common that can be isolated into its own file which then also includes the equate operation.

Regards,
Rien

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

···

On 08 Dec 2016, at 13:52, Aron Lindberg <aronl@me.com> wrote:

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

DevAndArtist · December 8, 2016, 1:05pm

Overkill or not, grouping files into a folder/group + folderprivate smells exactly like a submodule to me. ;)

The only thing I’m repeating over and over is that we should fix that open mess and allow protocols to have the same open/public access level as classes have.

open protocol from module A is allowed to be conformed to from module B
public protocol from module A can only be used as an interface in module B

···

--
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 13:52:27, Aron Lindberg (aronl@me.com) schrieb:

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

jeremyp · December 8, 2016, 5:32pm

To conform to Equatable, the arguments to == need to have the same type.

However there might be other operators for which you might conceivably want to do this. I think the right long term answer to this is submodules and submodule visibility. For the present, I would argue that a source file isn’t messy just because it is long. So I’d put them in the same file or raise the read visibility of the properties the operator depends on to internal.

···

On 8 Dec 2016, at 12:52, Aron Lindberg via swift-evolution <swift-evolution@swift.org> wrote:

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?

Aron_Lindberg1 · December 8, 2016, 1:16pm

It is hard to argue with that :)

I think the problem with more or less all new access level modifiers is that while there are legit uses for folderprivate, typeprivate and what else have been proposed recently, all of them also allow for some pretty no-legit anti-pattern uses as well.

I will go back to my long swift files and fileprivate now ;)

/Aron

···

On 8 Dec 2016, at 14.05, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Overkill or not, grouping files into a folder/group + folderprivate smells exactly like a submodule to me. ;)

The only thing I’m repeating over and over is that we should fix that open mess and allow protocols to have the same open/public access level as classes have.

open protocol from module A is allowed to be conformed to from module B
public protocol from module A can only be used as an interface in module B

--
Adrian Zubarev
Sent with Airmail

Am 8. Dezember 2016 um 13:52:27, Aron Lindberg (aronl@me.com <mailto:aronl@me.com>) schrieb:

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

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