[swift-evolution] access control

[Ilya Belenkiy]

Great, thank you!
On Thu, Jan 28, 2016 at 12:05 PM Douglas Gregor <dgregor at apple.com> wrote:

> On Jan 27, 2016, at 4:43 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I am not sure who to ask, so I’ll ask here:
>
> At what stage do proposals get merged into the “proposals” folder? Is
> there some order in which proposals get scheduled for review? My proposal
> was thoroughly discussed twice on this list. Is there anything else that I
> can do to get it scheduled for a review?
>
>
> One of the core team members will get it merged today. Sorry for the
> delay! There is a *lot* going on in swift-evolution land.
>
> - Doug
>
>
> On Jan 26, 2016, at 9:29 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
>
> This is certainly not what I wrote. What I said is that hiding the private
> interface becomes a practical concern on large scale, when you deal with
> projects or libraries. Swift already solves that issue with per-file and
> per-module visibility. And when editing the narrow scope (the file), one
> should make sure that one knows that they are doing (not unlike what you
> wrote yourself).
>
>
> Why not automate it if we can?
>
> Oh, I quite agree with you here. But I still don’t think that declaration
> scope access is really necessary to achieve this (because quite honestly,
> the future-Taras messages are best conveyed through documentation strings
> :) ).
>
>
> Would you remove all type checking and rely solely on the documentation to
> make function calls? If you wouldn’t, exactly the same reasoning applies to
> *where* a function can be called.
>
> I do not believe that your example is even remotely appropriate. These
> problems are on a totally different scale. You can’t seriously mean the the
> lack of definition scope access poses challenges that are even remotely
> similar to those associated with the lack of type checking.
>
>
> I can and I do. Data encapsulation is a cornerstone for object oriented
> programming for a very good reason.
>
> No compiler sugar will prevent people from using your internal APIs if
> they want to.
>
>
> True, but the same applies to type checking. We should have real data
> encapsulation for exactly the same reason.
>
> At any rate, I can’t help but notice that we are going in circles here.
>
>
> We are. I hope that my pull request with the proposal will be merged and
> reviewed soon. This issue has already received plenty of discussion here.
>
> On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko at uzh.ch> wrote:
>
> On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> By this logic, you don't want or need private (Swift's private-to-file)
> either. You just want/need internal and public, because you trust your
> judgement and you want access to everything in the project.
>
>
> This is certainly not what I wrote. What I said is that hiding the private
> interface becomes a practical concern on large scale, when you deal with
> projects or libraries. Swift already solves that issue with per-file and
> per-module visibility. And when editing the narrow scope (the file), one
> should make sure that one knows that they are doing (not unlike what you
> wrote yourself).
>
> I'm not arguing that Swift needs, say, Scala's level of detail in its
> access modifiers, but I think an access modifier for private-to-class or
> private-to-instance or private-to-scope would let past-Rob convey useful
> information to future-Rob in a lot of places where currently the
> information is less precise or entirely absent, and that this ability is
> useful enough to justify the additional language complexity.
>
>
> Oh, I quite agree with you here. But I still don’t think that declaration
> scope access is really necessary to achieve this (because quite honestly,
> the future-Taras messages are best conveyed through documentation strings
> :) ). See also the summary at the end of my mail. Subclass scope is a
> different story, because it has many practical uses, but thats a topic for
> another discussion.
>
> On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> The reasoning is the same as having real types instead of conventions for
> naming objects:
>
>
> I do not believe that your example is even remotely appropriate. These
> problems are on a totally different scale. You can’t seriously mean the the
> lack of definition scope access poses challenges that are even remotely
> similar to those associated with the lack of type checking.
>
> There are plenty of discussions about Cocoa private APIs on the web where
> the only thing that is stopping people is whether using them will pass the
> app store check (and if there is a secret back door still). That specific
> boundary is addressed with “internal”, but the same is true at the scale of
> a class.
>
>
> No compiler sugar will prevent people from using your internal APIs if
> they want to. With Objective-C this is particularly easy, due to the
> dynamic nature of the language. Even if Swift had the definition scope
> access modifier, one could get access to your private interface by
> reverse-engineering the memory layout of your object and accessing the
> state directly. The only real argument in favour of definition scope is bug
> prevention, and as far as I am concerned, it is a matter of opinion (I do
> like your point about autocompletion though). Again, as I wrote before, I
> am ambivalent. I don’t think that Swift will loose anything by introducing
> definition scope access but I also don’t think that it will gain anything.
>
> At any rate, I can’t help but notice that we are going in circles here. I
> think that the decision should be made by the core Swift team, who should
> evaluate how well it fits with their vision.
>
> Best,
>
>  Taras
>
> On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This a great writeup on clarity of intent. I’d like to add that in
> principle, if clarity of intent was the only goal, it could be achieved by
> a universally agreed on convention, like putting _ in front of the method
> or property (or type) . We could put it in guidelines and rely on it in all
> Swift projects. The other part that it is enforced by the compiler is
> equally important. The reasoning is the same as having real types instead
> of conventions for naming objects:
>
> Imagine that the Swift compiler did nothing for types — it was just a
> useful way to convey the coder’s intent. Maintaining the code in this
> context would become much more difficult:
>
> 1) the compiler would not help catch mistakes.
> 2) the tools would not provide contextual auto completions or useful type
> related information in general
>
> I am sure that everyone would be less comfortable shipping a large
> codebase that didn’t go through all the type checks. Exactly the same
> reasoning applies to “local”. If it’s just a convention that is not
> enforced by the compiler, we lose a very useful way to verify code
> correctness. In addition to that, everything that is marked as “local” (or
> “_” in front of the name)  now shows up in code completions and adds noise
> and temptation to cut corners (often this would be “faster” functions that
> already assume certain things about the state that may generally not be
> true). There are plenty of discussions about Cocoa private APIs on the web
> where the only thing that is stopping people is whether using them will
> pass the app store check (and if there is a secret back door still). That
> specific boundary is addressed with “internal”, but the same is true at the
> scale of a class.
>
> On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I agree with everything Matthew Johnson said in his response. In addition:
>
> On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Personally, I use it quite often because of the way I like to design
>> things as groups of tightly interdependent components (friends, if you
>> want) who are aware of each other’s inner workings. I also want to have
>> full access to the interface of any project I work on because I trust
>> myself to make the judgement whether I am allowed to use a particular
>> functionality or not.
>
>
> By this logic, you don't want or need private (Swift's private-to-file)
> either. You just want/need internal and public, because you trust your
> judgement and you want access to everything in the project.
>
> I trust my judgement, but I don't trust my memory. In six months, I won't
> remember every detail of the code I wrote today. Private-to-file is a
> message from past-me to future-me: "Dear future-Rob, you don't need to
> worry about looking for any use of this element outside this file, but if
> you want to make it visible to other files, you better study it to make
> sure it's safe to expose. Warmest regards, past-Rob."
>
> This is a useful message. It helps jog future-Rob's memory, it saves
> future-Rob from bugs, and it lets past-Rob rest easy because the message is
> guaranteed to be delivered, and is guaranteed to be correct. No comment or
> policy or convention can make that guarantee.
>
> I want the ability to send another useful message: "Dear future-Rob, you
> don't need to worry about looking for any use of this element outside this
> class, but if you want to make it visible to other classes, you better
> study it to make sure it's safe to expose. Very truly yours, past-Rob."
>
> Note that moving a private class to its own file to make its privates more
> private does not work. Now I have to make the formerly-private class an
> internal class, so I'm not sending the first message anymore.
>
> I'm not arguing that Swift needs, say, Scala's level of detail in its
> access modifiers, but I think an access modifier for private-to-class or
> private-to-instance or private-to-scope would let past-Rob convey useful
> information to future-Rob in a lot of places where currently the
> information is less precise or entirely absent, and that this ability is
> useful enough to justify the additional language complexity.
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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/20160128/00e41dac/attachment.html>