On Nov 24, 2015, at 16:16 , Roland King <r...@rols.org> wrote:
> if I define an internal class which implements a public protocol, who is able
> to call the methods in that protocol? Anyone (it’s a public protocol), only
> classes in the same framework or source file (the class is internal)?
Anyone. However, not everyone can get a reference to an object of the class
directly, because the class is internal. Classes outside the framework could,
though, receive a reference to your object as type “object conforming to the
public protocol” from some other source, and call the protocol methods on your
internal object, but not any of its other methods.
At least, that’s what I would expect. I haven’t tested it.
> In this instance I have an internal class implementing the CBCentralManager
> protocol and yet if I supply this as a delegate, CoreBluetooth is able to
> call those internal methods just fine. I suspect in this case it’s because
> we’re actually in the ObjC world here (the protocol extends NSObjectProtocol)
> and in the ObjC world if you can find it, you can call it.
Maybe because of Obj-C, but this would be covered under the above scenario
anyway. The delegating object wouldn’t know about any methods other than those
in the protocol.
> The compiler messages don’t really help to figure out what the rules are, if
> I have this
>
> <access specifier> Class Foo : NSObject, CBCentralManagerDelegate
> {
> func centralManagerDidUpdateState(.. ) ..
> //
> required
> func centralManager(central:CBCentralManager,
> didConnectPeripheral:CBPeripheral)
> //optional
> }
>
> if access specifier is public I get the message, for both of those
>
> centralManagerDidUpdateState() must be declared public because it
> matches a requirement in the public protocol CBCentralManagerDelegate
> ditto for centralManager(central:CBCentralManager,
> didConnectPeripheral:CBPeripheral)
Because the default method access is internal.
> if access specifier is internal I get nothing, all compiles fine
Because the default method access is internal.
> if access specifier is private I get a very odd combo
>
> centralManagerDidUpdateState has no errors or warnings at all
> centralManager(central:CBCentralManager,
> didConnectPeripheral:CBPeripheral) gives the message “Non-@objc method
> centralManager(central:CBCentralManager, didConnectPeripheral:CBPeripheral)
> cannot satisfy optional requirement of @objc protocol
> CBCentralManagerDelegate’
>
>
> I find this confusing because the protocol is public, the error message when
> making the class public makes sense, it’s telling me that public protocols
> need public methods. The last one I don’t get at all, why should making the
> class private stop the methods being implicitly @objc?
I dunno. One thing that’s different when the class is private is that methods
can be inferred to be final, and maybe final implies non-@objc.
_______________________________________________
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
