[swift-evolution] access control proposal

Tue Dec 15 10:49:26 CST 2015

There are a lot of unreasonable assumptions here. That's all I have to say
in response.

--
Ilya Belenkiy

On Tue, Dec 15, 2015 at 11:35 AM Colin Cornaby <colin.cornaby at mac.com>
wrote:

> I guess where I get skeptical is the example case. In this example, a
> module that should otherwise be simple but is made complicated by having
> too many source files in Swift is really a module that should be simple,
> but has been made complicated by too many custom types. If we’re talking
> about a simple module that has been overcomplicated by too many types
> (Swift scoping aside), we’re talking about a module that likely has
> significant architectural problems. That’s why I asked if there were any
> examples. I was wondering if there were any cases where a project’s design
> was otherwise sound, but maintainability was compromised by a lack of fine
> grain scoping in Swift. What’s been talked about so far seems to really be
> Swift source that is suffering from design issues or overbuilding, and
> instead of fixing those design issues that’s leading to a large number of
> source files, we’re talking about paving over those design issues with new
> language constraints.
>
> I don’t know where the Swift team falls in having Swift as a language that
> supports questionable development practices. But to me, I’m still just not
> convinced the work to change this would be justified by any real gain in
> good development practices.
>
> On Dec 15, 2015, at 4:10 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
>
> This is a matter of opinion. I think that the proposal is very much in
> line with Swift's emphasis on strong types and protocols and adds clarity
> about where an API can be used.
>
> --
> Ilya Belenkiy
>
> On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby at mac.com>
> wrote:
>
>> I don't think this analogy follows. Books have division lines of pages or
>> chapters that compartmentalize information. In the same way, development
>> projects traditionally have a separation of concerns that are organized
>> using different source code files. I don't know if a "gazillion" accurately
>> captures the number of files required to separate concerns. On the other
>> hand, I'm also not sure if Swift should try to enforce good development
>> practices as policy (but I like the practice it's trying to support here.)
>>
>> I'm just watching this from the sidelines, but I haven't seen a
>> compelling example case anywhere in the discussion that would lead to just
>> an unmaintanable number of files. Even for multiple teams all working on
>> the same source... separation of files seems like the cleanest solution.
>>
>> As others have mentioned, iOS and Mac development (as well as open source
>> Swift) seems to be going in the direction of a single application or
>> project containing multiple modules. Mac has been doing that with great
>> success for a long time. Given that's the direction things are going,
>> private as it exists now even seems a little heavy for a lot of uses. It's
>> completely realistic the projects are going to start separating concerns
>> over module boundaries and not just source file boundaries. This proposal
>> just seems to be going the opposite way that Swift and Apple platform
>> development is going.
>>
>> Files are easy to understand, and they're lightweight, and I just haven't
>> been convinced that files with small amount of source are even a bad thing,
>> nor have I seen Swift projects out in the wild that have too many short
>> Swift source files that is a result of language restrictions. Do you have
>> any examples of projects out in the community?
>>
>> On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
>> wrote:
>>
>> Please take a look at the other posts today. I addressed this concern
>> earlier. In one sentence, just like you wouldn't want to put every
>> paragraph of a book or every section of an article in an encyclopedia in a
>> separate file, you wouldn't want to end up with a gazillion files just to
>> ensure that implementation details of an API stay hidden in a way that is
>> enforced by the compiler.
>>
>> --
>> Ilya Belenkiy
>>
>> On Mon, Dec 14, 2015 at 2:19 PM Colin Cornaby via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> (I'm reading the upstream discussion but I'll reply here.)
>>>
>>> I don't know if I really like the pattern this is trying to support. I
>>> like that Swift makes it cleaner to include multiple types in a single
>>> Swift file. But I feel like this proposal is trying to take things too far
>>> the other way. Types that should should only see each other from a non
>>> "friends" role should be in separate files.
>>>
>>> What's proposed doesn't really harm someone who likes the "multiple
>>> file" style directly, but I don't want to see projects where everything
>>> gets jammed into one file. I think keeping the scope of private (with no
>>> new keywords) to the same file encourages good coding practices.
>>>
>>> I've really liked the balance Swift strikes in this case. I feel like
>>> this discussion is going to come down to opinion, but projects that I've
>>> worked in that have tried to over compact have always run into issues. I
>>> don't know if it's the role of the language to push an ideology either way,
>>> but personally I like the direction Swift is pushing. Files make for good
>>> scope boundaries.
>>>
>>> On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> I think the it would help a great deal to have an access level modifier
>>> that is really private and visible only inside the class itself. Right now,
>>> the only way to hide implementation details for a class is to hide the
>>> class code in a separate file, which is very inconvenient for several
>>> reasons:
>>>
>>> 1) the meaning of the code changes depending on which file the class is
>>> in. It's very easy to accidentally expose class internal details and then
>>> call class elements that are meant to be used only inside the class. Having
>>> a keyword for class internals will allow the compiler to ensure that only
>>> the public API for the class is used from the outside world. The user can
>>> check types on his own, but it's better that the compiler does it
>>> automatically. Similarly, the user can check that only the proper APIs are
>>> called, but it's better that the compiler does it automatically.
>>>
>>> 2) accessibility by file structure may cause some really short files.
>>>
>>> 3) It's impossible to group related classes in one file but still hide
>>> implementation details inside each class
>>>
>>> I think that it the best solution is to make private keyword do what it
>>> states -- keep the class element private to the class. But if it's really
>>> important to have a separate keyword for backward compatibility, it would
>>> be the next best thing.
>>>
>>> --
>>> Ilya Belenkiy
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/88c3ea36/attachment.html>