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

Saagar Jha saagar at saagarjha.com
Thu Dec 8 06:55:41 CST 2016


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 at 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 at beryle-lee.com <mailto:jim.malak at beryle-lee.com>) schrieb:
> 
>> Great. Is there some other steps I should go through or is the next step to write a draft proposal?
>> 
>> Kind regards,
>> Jim Malak
>> Director
>> Beryle & Lee, Inc,
>> O +1-330-818-2600
>> M +1-234-716-2658
>> F +1-330-818-2560
>> 
>> email/Skype: jim.malak at beryle-lee.com <mailto:jim.malak at beryle-lee.com>
>> http://beryle-lee.com <http://beryle-lee.com/>
>> http://linkedin.com/in/jamesmalak <http://linkedin.com/in/jamesmalak>
>> https://www.facebook.com/BeryleLeeInc <https://www.facebook.com/BeryleLeeInc>
>> From: Aron Lindberg <aronl at me.com>
>> Sent: Thursday, December 8, 2016 7:34:06 AM
>> To: Jim Malak
>> Cc: Adrian Zubarev; swift-evolution at swift.org
>> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?
>>  
>> Since Xcode is not a requirement for Swift development no, I was talking about a file system folder.
>> 
>>> On 8 Dec 2016, at 13.30, Jim Malak via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I totally agree.  For clarity, are we in agreement that the definition of "folder" is the underlying file system's implementation of a folder rather than some metadata setting? I am thinking of how Xcode as a view of project folder that at times can leave on one confused.
>>> 
>>> My preference is to keep it simple, to use the underlying file system to decide what is a folder. Does that sound ok?
>>> 
>>> Kind regards,
>>> Jim Malak
>>> Director
>>> Beryle & Lee, Inc,
>>> O +1-330-818-2600
>>> M +1-234-716-2658
>>> F +1-330-818-2560
>>> 
>>> email/Skype: jim.malak at beryle-lee.com <mailto:jim.malak at beryle-lee.com>
>>> http://beryle-lee.com <http://beryle-lee.com/>
>>> http://linkedin.com/in/jamesmalak <http://linkedin.com/in/jamesmalak>
>>> https://www.facebook.com/BeryleLeeInc <https://www.facebook.com/BeryleLeeInc>
>>> From: Aron Lindberg <aronl at me.com <mailto:aronl at me.com>>
>>> Sent: Thursday, December 8, 2016 6:26:10 AM
>>> To: Adrian Zubarev
>>> Cc: Jim Malak; swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?
>>>  
>>> I think this is a great idea!
>>> 
>>> I would prefer calling it folderprivate tho.
>>> 
>>>> On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Whoops I meant directoryprivate not dictionaryprivate. I’m probably still sleepy. 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>> 
>>>> Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev (adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>) schrieb:
>>>> 
>>>>> You haven’t seen this in the list because no one requested dictionaryprivate yet. :D
>>>>> 
>>>>> @core-team: See what you have done with >>file<<private thing. 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 at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>>>> 
>>>>>> My apologies up front if I am going about this incorrectly. I have been exploring extensions in Swift 3 both as a part of protocol-oriented programming and as a way to encapsulate related code to improve readability and maintainablity of otherwise more complex classes I have designed. I am able to encapsulate methods and calculated properties in extensions and restrict their use to the object type I am extending as long as everything is in one file via fileprivate. 
>>>>>> 
>>>>>> I would like to be able to have my class or structure file in a directory that contains my associated extensions  (also in separate files) and be able to restrict the access  of appropriate properties and  methods to that common directory. This would allow the same level encapsulation as fileprivate with the benifit of being able to organize code into sepereate files based on function.
>>>>>> 
>>>>>> I did not see this in the commonly rejected list but am unsure if this is something that is out of scope for 4.0. Is this something I can write up a proposal for? Is there some other approach that I missed that I should be using instead?
>>>>>> 
>>>>>> Kind regards,
>>>>>> Jim Malak
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161208/b5b9b8ca/attachment.html>


More information about the swift-evolution mailing list