[swift-evolution] Protected Access

Callionica (Swift) swift-callionica at callionica.com
Fri Oct 7 18:36:21 CDT 2016


For overridable, but not callable, you can use the technique outlined at
http://www.callionica.com/developer/#swift-protected
(give your method a parameter of a type that only the base class can create)

On Friday, October 7, 2016, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> The discussion of private/fileprivate reminded me of other access modifier
> issues that have been bugging me.  I agree that the old system is better,
> but I am ambivalent about changing it back…
>
> What I pretty much constantly want is an access modifier which lets me
> access something from an extension (which is potentially in a different
> file), but otherwise have it be private.  The vast majority of my use of
> “fileprivate” is so that I can access internal properties/functions from an
> extension (which I am forced to place in the same file).
>
> Access from subclasses is a larger discussion, but I run into this most
> often with Structs and their extensions.
>
>
> The other pieces which seem to be missing are modifiers which allow finer
> grained control of how class methods are overridden and used.
>
> It is a fairly common pattern in cocoa, for example, to have customization
> point methods which are designed to be overridden, but are not supposed to
> be called directly. Right now, this is enforced via documentation.  One
> potential solution is to have a @noExternalCall attribute which says that
> it can only be called from the class/subclass/extensions… but if you think
> about it, this is basically another view of the first issue. If we could
> mark that method as only visible within the class/subclasses/extensions,
> then the behavior we want just falls out naturally. It can’t be called
> externally, because no one on the outside can see it.
>
> I also occasionally run into this with protocols.  I find that I have a
> property on the protocol which is needed for default implementations, but I
> really want to make it private with respect to the protocol (and its
> inheritors/extensions).  That is, I want the implementor of the protocol to
> have visibility for that property, but not the caller of the protocol.
> Right now, I have to expose it to everyone (which clutters my external
> API), and then note in documentation not to call those properties.
>
> Basically, I want to do the following:
>
>         protocol P {
>                 hidden var a:Int
>                 var b:Int
>         }
>
>         extension P {
>                 var c:Int { return self.a + self.b}
>         }
>
>         struct A:P {
>                 private var a:Int = 5  // ‘A’ must implement, but it
> doesn’t have to expose it externally
>                 var b:Int = 2
>         }
>
>         struct B:P{
>                 var a:Int = 3  // ‘B’ chooses to expose, which is ok too
>                 var b:Int = 4
>         }
>
>         let ans = A().c  // 7
>         let ohNo = A().a // Error!
>
> Basically ‘hidden’ in the protocol means that the implementor must
> implement the property, but it is not required to expose it to the world.
> I don’t really care whether that is spelled hidden, protected, or private,
> but I would use this fairly often.
>
> Thanks,
> Jon
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161007/759d26ac/attachment.html>


More information about the swift-evolution mailing list