[swift-evolution] final + lazy + fileprivate modifiers

Vladimir.S svabox at gmail.com
Fri Feb 17 12:45:07 CST 2017


On 17.02.2017 20:48, Xiaodi Wu wrote:
> What you are really asking for is a way of flexibly designating a "unit of
> code" within a module, for which the general solution is submodules. The
> objection is that, instead of tackling that issue, these are suggestions to
> invent ad-hoc units of code (scope + extensions only in the same file,
> scope + extensions only in the same module, class + extensions only in the
> same file + subclasses only in the same module), and it is possible to
> invent arbitrary many of these.

No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each 
type in its own submodule/file. IMO it is very naturally to have a need to 
protect access to some details *even* in the same file(please find David 
Sweeris's answer in previous email in this thread. with current 'private' 
he can *guarantee* that no code touches internal props even in the same 
file), also many of us need a way to share some details only for 
extensions/subtypes in other files in the same module/submodule even just 
to organize code as *one* need/want and to express intention about who 
should "touch" this code and get help from compiler when accidentally try 
to use protected method/prop.

Someone, who want just internal/public can use only them in own code, no 
problems. But many feels that they need a more detailed access levels to 
structure their code, they find current situation not comfortable.


>
> There is, objectively, an actual minimum number of access modifiers, which
> is two. Those two are: visible only inside the unit of code, or visible
> both inside and outside the unit of code. In Swift, those are spelled
> internal and public. Everything else here is really talking about better or
> more flexible ways of defining a unit of code.
>
>
> On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
>     >
>     >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
>     >> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>
>     wrote:
>     >>
>     >> True, what I meant was a wider feedback - let's face it, there are many
>     >> more Swift developers now than 2 years ago.
>     >>
>     >> My objection is not to the documentation itself, but to the fact
>     that I'm
>     >> unnecessarily exposing an internal implementation detail to the rest of
>     >> the module. Being able to hide it from the rest IMHO leads to better
>     >> though-through API that is indeed meant to be exposed; whereas exposing
>     >> internal details leads to allowing various quick hacks instead. We know
>     >> these quick hacks very well from the ObjC world by accessing private
>     >> parts of the object via duck typing or setting values via KVO.
>     >>
>     >> At least this is my experience with which the less implementation
>     details
>     >> are exposed to the outer world, the better.
>     >
>     > I think the fundamental disagreement we’re seeing in this thread is the
>     > meaning of “outer world”; to some, it means “users of your module”. To
>     > others, it also means “other developers on my team who are working on
>     other
>     > files in the module”.
>     >
>     > Personally I feel enforced encapsulation of implementation detail to the
>     > latter group is less important than the former, and can be handled by
>     > convention. Whereas other users of your module definitely benefit from
>     > access control and being able to consume a clearly-defined interface.
>
>     I assume we are discussing access modifiers mainly for the former group,
>     i.e. when we are "inside" the module (even when this module is written by
>     the same one person, and especially when it is written by the group).
>
>     "handled by convention" - are we talking about something like declaring
>     props and methods as __privateprop , m_privateprop etc and write comments
>     to mark that they should not be used outside of some scope? Is it really
>     Swifty and acceptable for the modern language? Will this help to prevent
>     some mistakes with incorrect access? Is it better than simple and clean
>     schema for access modifiers and compiler's help?  I don't understand this.
>
>     IMO, access modifiers is very known and handy abstraction to distinct
>     levels of access and to structure code many developers knows about and use
>     in other languages.
>     At the end, if one wants to keep all internal - no problems!, you can do
>     this right now, just don't use fileprivate/private/etc.
>
>     Yes, I agree we need a simple and clean schema, not over-complicated, we
>     need nice&clean keywords, we need a required minimum of access modifiers,
>     not more, and I do believe currently we don't have this minimum.
>
>     Was already suggested, trying again(I do believe this could be a
>     compromised solution to suit needs of the main part of developers):
>     * (as currently) public/open -> outside of the module
>     * (as currently) internal -> inside module
>     * private -> inside file (instead of fileprivate)
>     * protected(or *other* keyword) -> inside file + subtype&extensions in the
>     *same module*
>
>     What objections could be made for this?
>     Thank you.
>
>     >
>     > Slava
>     >
>     >>
>     >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <xiaodi.wu at gmail.com
>     <mailto:xiaodi.wu at gmail.com>
>     >>> <mailto:xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>>> wrote:
>     >>>
>     >>> That blog post starts out right away to say that it's a response to
>     >>> community feedback. Moreover, the scenario you describe was just as
>     >>> possible in 2014 as it is now. Finally, then as now, it's unclear why
>     >>> you consider documentation to be "not pretty." After all, your reader
>     >>> would need to consult the documentation before using a variable anyway.
>     >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution
>     >>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>
>     wrote:
>     >>>
>     >>>     I'm aware of this, but that's fairly a long time ago - before Swift
>     >>>     was open source and had community feedback and before Swift was
>     used
>     >>>     widely among developers.
>     >>>
>     >>>     To me, real-world use of the language has shown some flaws of
>     >>>     missing a protected access control, mainly having to decide between
>     >>>     having a variable internal or cramming all of the class extension
>     >>>     into one file, making it a 3KLOC mess. Either solution is not
>     pretty
>     >>>     - now I have it split among several files with an internal variable
>     >>>     commented as "Do not use, for private use of this class only."
>     >>>
>     >>>>     On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez
>     >>>>     <cheyo at masters3d.com <mailto:cheyo at masters3d.com>
>     <mailto:cheyo at masters3d.com <mailto:cheyo at masters3d.com>>> wrote:
>     >>>>
>     >>>>     https://developer.apple.com/swift/blog/?id=11
>     >>>>
>     >>>>
>     >>>>
>     >>>>     On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution
>     >>>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>
>     wrote:
>     >>>>
>     >>>>>     How about removing fileprivate, getting Swift 2 meaning of
>     private
>     >>>>>     (as most people here now suggest) and add additional @protected
>     >>>>>     annotation for those who want a more fine-grained solution:
>     >>>>>
>     >>>>>     @protected private - members accessable only from the
>     >>>>>     class/struct/enum/... and their extensions within the file
>     >>>>>
>     >>>>>     @protected internal - again, but you can access it even from
>     >>>>>     extensions and subclasses outside of the file within the entire
>     >>>>>     module.
>     >>>>>
>     >>>>>     @protected public/open - the same as above, but outside the
>     modules.
>     >>>>>
>     >>>>>     To me, this way most people here will be happy:
>     >>>>>
>     >>>>>     - those wishing the access control gets simplified - it in fact
>     >>>>>     does, you don't need to use @protected, if you don't want
>     to/need to.
>     >>>>>     - those who need a fine-grained solution, here it is.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>>     On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution
>     >>>>>>     <swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org>>> wrote:
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>>     Sent from my iPad
>     >>>>>>
>     >>>>>>>     On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution
>     >>>>>>>     <swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org>>>
>     >>>>>>>     wrote:
>     >>>>>>>
>     >>>>>>>
>     >>>>>>>>     On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution
>     >>>>>>>>     <swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org>>>
>     >>>>>>>>     wrote:
>     >>>>>>>>
>     >>>>>>>>     While we’re bikeshedding, I’m going to add my two cents. Hold
>     >>>>>>>>     on to your hat because this might be controversial here.
>     >>>>>>>>
>     >>>>>>>>     I think both ‘private’ and ‘fileprivate’ are unnecessary
>     >>>>>>>>     complications that only serve to clutter the language.
>     >>>>>>>>
>     >>>>>>>>     It would make a lot more sense to just have internal and
>     public
>     >>>>>>>>     only. No private, no fileprivate, no lineprivate, no
>     protected.
>     >>>>>>>>     It’s all silly.
>     >>>>>>>
>     >>>>>>>     Eh, I've used `private` to keep myself honest in terms of going
>     >>>>>>>     through some book-keeping functions instead of directly
>     >>>>>>>     accessing a property.
>     >>>>>>
>     >>>>>>     This is exactly the kind of thing I like it for and why I
>     hope we
>     >>>>>>     might be able to keep scoped access even if it gets a new name
>     >>>>>>     that ends up as awkward as fileprivate (allowing private to
>     >>>>>>     revert to the Swift 2 meaning).
>     >>>>>>
>     >>>>>>>
>     >>>>>>>     - Dave Sweeris
>     >>>>>>>     _______________________________________________
>     >>>>>>>     swift-evolution mailing list
>     >>>>>>>     swift-evolution at swift.org
>     <mailto:swift-evolution at swift.org> <mailto: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 <mailto:swift-evolution at swift.org>
>     <mailto: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 <mailto:swift-evolution at swift.org>
>     <mailto: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 <mailto:swift-evolution at swift.org>
>     <mailto: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 <mailto:swift-evolution at swift.org>
>     <mailto: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 <mailto:swift-evolution at swift.org>
>     > 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
>


More information about the swift-evolution mailing list