[swift-evolution] Protected Access

[Xiaodi Wu]

Jon--earlier in the week, there was another thread which once against
raised the idea of internal or private protocol conformances; would that be
another way of addressing your use case here?


On Fri, Oct 7, 2016 at 6:36 PM, Callionica (Swift) via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>> 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/20161007/6ef5d152/attachment.html>