On Jun 16, 2015, at 21:58 , Roland King <r...@rols.org> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
