[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Gonçalo Alvarez Peixoto]

Hey, Robert!

Thanks for your feedback.

I do believe that it is a common practice, and a good one as well, to have
your code broken down into separate extensions, either for improving code
readability by reducing the size of the implementation file, as well as
creating context for feature development.

Also, I do agree that one should have separate classes, structs, enums or
whatever better fits the purpose, handle code regarding a single
responsibility. However, should this responsibility remain within the scope
of the type we're implementing it on, it's best to have the code split into
separate extensions on separate files (so to avoid large and hard to
inspect files), and have these extensions access members which, would *no
longer* *be visible* to the whole module. I do believe, having these
members marked as *internal* creates the conditions for one to *scatter*
 and *decompose *a type since it opens the door for type in the module to
lay hands on it's members. *Typeprivate* would prevent these members to be
accessed from everywhere in the module, while enabling them to be reached
from everywhere within their type.

Also, I believe that having the scope of a member limited by file scope
does does fall short in fitting a language design purpose, as file is a
compiler related construct which could, in turn, be replaced somewhere in
time, thus leaving the “fileprivate” access member orphaned.

Best,
Gonçalo

2016-11-29 16:13 GMT+00:00 Robert Widmann <devteam.codafi at gmail.com>:

> Is that a particularly common case?  I haven’t written code that needs
> access patterns like this and it strikes me as strange that anything you’re
> willing to expose to extensions scattered throughout your codebase you’d
> also prefer not to export throughout a module that you have complete
> control over.  Sure, it might be “cleaner” to scope your variables to the
> implementation, but past a certain point it just seems to encourage extreme
> decomposition and scattering of a single class or structure when you should
> be separating your implementation into multiple classes and structures.
>
> On Nov 29, 2016, at 11:07 AM, Gonçalo Alvarez Peixoto <
> goncalo.alvarezpeixoto at gmail.com> wrote:
>
> Robert,
>
> Thanks for your feedback.
>
> However, I tend to disagree with you.
>
> *"The proposal, as it stands, does nothing to indicate how this is much
> different from internal - all examples given would trivially be solved by
> internal members."*
> This proposal aims at covering all of the cases in which you *do not want* to
> expose your properties *internally. *For instance, you might want to
> access a member of a view controller from an extension of this view
> controller on another file, but not make it accessible from other members
> in the module (which is what *internal *does).
>
> Best,
> Gonçalo
>
> 2016-11-29 15:53 GMT+00:00 Robert Widmann <devteam.codafi at gmail.com>:
>
>> The proposal, as it stands, does nothing to indicate how this is much
>> different from internal - all examples given would trivially be solved by
>> internal members.  I don’t think we need finer-grained access control to
>> address this, I think we need extensions, at least in the same file as
>> their parent declarations, to be able to define variables.
>>
>> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> Hello, everyone!
>>
>> I would like to introduce a new proposal to swift evolution, but first I
>> would love to run it by all of you so I get everyone's feedback and enrich
>> it.
>>
>> This proposal consists of introducing a new *typeprivate *access control
>> level which allows for members to be accessed in all extensions of a given
>> *type,* whether lying within or in another file.
>>
>> You'll find the proposal draft in:
>> https://github.com/goncaloalvarez/swift-evolution/blob/maste
>> r/proposals/NNNN-introduce-typeprivate-access-control-level.md
>>
>> Thanks in advance for taking the time to evaluate the proposal.
>>
>> Best regards,
>> Gonçalo
>> _______________________________________________
>> 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/20161129/5ca976a0/attachment.html>