[swift-evolution] final + lazy + fileprivate modifiers

Xiaodi Wu xiaodi.wu at gmail.com
Fri Feb 17 13:21:18 CST 2017


On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S <svabox at gmail.com> wrote:
>
>> 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.
>>
>
> I reject the premise that it is a goal of the Swift compiler to protect
> you from yourself.
>

I should clarify, it should certainly protect you from unintentional
accidents that you make, where those are foreseeable, etc. But here we're
talking about _you_ invoking functions that _you_ wrote, which is a pretty
darn clear demonstration of intentionality. And so what I mean to say is
that the Swift compiler, IMO, has no real business trying to protect your
intentions from your other intentions.

You can *guarantee* that nothing in the same file touches what it shouldn't
> touch *by your own eyes*; `private` makes it "easier" but it is by no means
> necessary. Indeed I argue that reading code should be the go-to way reason
> about the behavior of code, and that compiler help is justified only when
> such a method of reasoning is unusually hard or error-prone.
>
> Likewise, you can express intention by documentation. Indeed I argue that
> reading the documentation should be the go-to way for a reader to learn how
> to use unfamiliar code. Since a user will consult the documentation if he
> or she is wondering, "how or when should I use this method?", it is
> perfectly sufficient and elegant to put a sentence in the documentation
> that says, "actually, you should never use this method." It is self-evident
> why one might _want_ compiler help, but it is unclear to me why one _needs_
> compiler help for this: after all, if you call an internal method that
> doesn't behave as intended, you can read the source code to find out
> exactly why--you can even change it!
>
> 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.
>>
>
> As I said, there are arbitrarily many ways to structure your code. If you
> insist that the compiler should help you to control, perfectly, exactly
> what lines of code can call what other lines of code, and that the way to
> spell this desire is through access levels, then you will need many more
> access levels. My point is that, taken to its logical end, you would need
> infinitely many access levels. Although it would be unnecessary for the
> language to active prohibit certain styles of organizing code, I believe
> very strongly it is a non-goal of Swift to actively support, by the
> addition of new features, all imaginable styles of organizing code.
>
>
>
>>
>>
>>> 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/dee751d5/attachment.html>


More information about the swift-evolution mailing list