Re: access modifiers in protocols
Re: access modifiers in protocols
- Subject: Re: access modifiers in protocols
- From: Quincey Morris <email@hidden>
- Date: Wed, 17 Jun 2015 05:15:44 +0000
On Jun 16, 2015, at 21:58 , Roland King <email@hidden> wrote:
>
> Is there a good linguistic reason why access modifiers which restrict access should not be allowed in protocols? I mean something like this
>
> public protocol Foo
> {
> mutating func foo( Int )->Void
> internal var bar : Array<Int> { get set } // <- can’t do this
> }
It seems to me that “public” here means “all these methods are the public API of types conforming to Foo". Therefore, it wouldn’t make sense to specify any access controls on individual properties/methods.
The rest of your explanations is TMI, I can’t wrap my brain around it, but why can’t you do this:
> public protocol Foo
> {
> mutating func foo( Int )->Void
> }
>
> internal protocol FooImplementedWithArray : Foo
> {
> var bar : Array<Int> { get set }
> }
>
> extension FooImplementedWithArray
> {
> public mutating func foo( i : Int ) -> Void { bar.append( i ) }
> }
and have individual types conform to Foo or FooImplementedWithArray, depending on which default implementation you want?
The other aspect is that there’s a difference between just having a default implementation in a protocol and extension, and having that *plus* a constraint specifying the same property/method in the original protocol. This was touched on briefly, late in the POP video, but it went by so fast I didn’t get to think about the implications for scenarios like the one you’re considering.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden