[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