Re: Swift - internal class conforming to public protocol

[Andreas Mayer]

> Am 25.11.2015 um 08:13 schrieb Marco S Hyman :
> 
> As I read that adopting a public protocol requires the methods that implement 
> the protocol to be public (but only those methods).

That's not how I read it. And it does not to work that way either. This 
compiles fine:

public protocol PublicProtocol {
func someFunction()
}

internal class SomeClass: PublicProtocol {
internal func someFunction() {
// implementation
}
}

I think it means you can't declare internal functions for a public protocol, 
whereas you can declare internal functions for a public class.

This does not compile:

public protocol OtherPublicProtocol {
internal func someFunction()
}

The compiler complains that "'internal' modifier cannot be used in protocols".


Andreas
___

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

Re: Swift - internal class conforming to public protocol

[Andreas Mayer]

> Am 25.11.2015 um 08:56 schrieb Quincey Morris 
> :
> 
>> That's explained in "Using Swift with Cocoa and Objective-C":
>> 
>> "The compiler does not automatically insert the @objc attribute for 
>> declarations marked with the private access-level modifier.”
> 
> That can’t be the full explanation, because the other private method doesn’t 
> produce an error, Roland said.

I can't replicate that behavior.

This doesn't work:

// Roland's protocol must be marked @objc since it has optional requirements.

@objc public protocol PublicProtocol {
func someFunction()
// ...
}

private class SomeClass: NSObject, PublicProtocol {
func someFunction() {
// implementation
}
}

Type 'SomeClass' does not conform to protocol 'PublicProtocol'
Fix-it: Candidate is not '@objc', but protocol requires it


Andreas
___

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

Re: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:30, Andreas Mayer  wrote:
> 
> 
>> Am 25.11.2015 um 08:56 schrieb Quincey Morris 
>> :
>> 
>>> That's explained in "Using Swift with Cocoa and Objective-C":
>>> 
>>> "The compiler does not automatically insert the @objc attribute for 
>>> declarations marked with the private access-level modifier.”
>> 
>> That can’t be the full explanation, because the other private method doesn’t 
>> produce an error, Roland said.
> 
> I can't replicate that behavior.
> 
> This doesn't work:
> 
> // Roland's protocol must be marked @objc since it has optional requirements.
> 
> @objc public protocol PublicProtocol {
>   func someFunction()
>   // ...
> }
> 
> private class SomeClass: NSObject, PublicProtocol {
>   func someFunction() {
>   // implementation
>   }
> }
> 
> Type 'SomeClass' does not conform to protocol 'PublicProtocol'
> Fix-it: Candidate is not '@objc', but protocol requires it
> 


I believe that is what I saw when I made the class private, it required an 
explicit @objc, in my case it said it required @objc because the method was 
optional. 

So after this discussion, which was as-usual helpful, I see why you can use a 
protocol in a class with lesser access rights. The last question I had was, if 
I define a private class to conform to a public protocol, and then arrange in 
the same source file a public class which creates an instance of the private 
one and returns it as a protocol type, can I then use it. And the answer was 
yes I can.  I had an entirely private Bar implementing a public protocol Foo 
and a public struct Baz in the same source file as Bar which had a 
returnAsFoo() method which returned a Bar .. as a Foo. I was able to use that 
in a playground even though Bar was entirely inaccessible from the playground. 

So this all makes more sense now. 



___

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

Re: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:37, Quincey Morris 
>  wrote:
> 
> On Nov 25, 2015, at 00:30 , Andreas Mayer  wrote:
>> 
>> I can't replicate that behavior.
> 
> Since Roland hasn’t contributed to this thread for 24 hours, I vote we blame 
> *him*. ;)
> 
> 

I just did - some of us occasionally sleep, I just occasionally slept at 4 in 
the afternoon just because I could. Then I went and tried the last question I 
had. 

Which thing of the many was Andreas saying he couldn’t replicate? 
___

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

Re: Swift - internal class conforming to public protocol

[Quincey Morris]

On Nov 25, 2015, at 00:30 , Andreas Mayer  wrote:
> 
> I can't replicate that behavior.

Since Roland hasn’t contributed to this thread for 24 hours, I vote we blame 
*him*. ;)

___

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

Re: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 16:30, Andreas Mayer  wrote:
> 
> 
>> Am 25.11.2015 um 08:56 schrieb Quincey Morris 
>> :
>> 
>>> That's explained in "Using Swift with Cocoa and Objective-C":
>>> 
>>> "The compiler does not automatically insert the @objc attribute for 
>>> declarations marked with the private access-level modifier.”
>> 
>> That can’t be the full explanation, because the other private method doesn’t 
>> produce an error, Roland said.
> 
> I can't replicate that behavior.
> 
> This doesn't work:
> 
> // Roland's protocol must be marked @objc since it has optional requirements.
> 
> @objc public protocol PublicProtocol {
>   func someFunction()
>   // ...
> }
> 
> private class SomeClass: NSObject, PublicProtocol {
>   func someFunction() {
>   // implementation
>   }
> }

here’s my distilled example

import CoreBluetooth
private class Bananas : NSObject, CBCentralManagerDelegate
{
func centralManagerDidUpdateState(central: CBCentralManager)->Void {
// do nothing, I care little for your state
}

func centralManager(central: CBCentralManager, didRetrievePeripherals 
peripherals: [CBPeripheral])
{
// do nothing, you retrieved peripherals, I don't care
}
}

with the private designator, you get a warning on the second function about 
optionality and @obcj, and an error, not on the first, but on the entire class 
telling you the first function needs to be marked @objc, but not for 
optionality reasons, just says that the candidate is not @objc but the protocol 
requires it. So they both need objc, but for slightly different reasons, and 
the errors are reported in slightly different ways

change it to internal, no errors, no warnings, as now expected

change it to public and you get errors on both functions telling you to make 
them public, also as now expected. 

___

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

Re: Swift - internal class conforming to public protocol

[Charles Srstka]

> On Nov 25, 2015, at 12:54 AM, Andreas Mayer  wrote:
> 
> And there's no @not-objc modifier.

There actually is a @nonobjc modifier. Can’t remember in which release they 
added it, but it’s there.

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html
 


Charles

___

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

Re: Swift - internal class conforming to public protocol

[Quincey Morris]

On Nov 24, 2015, at 16:16 , Roland King  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
> 
>  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

Re: Swift - internal class conforming to public protocol

[Andreas Mayer]

> 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)?

If you declare it internal it's internal. Adopting a public protocol doesn't 
change that.

> 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.

Access levels are applied at compile time only. Once you get it to compile, the 
runtime will not care. Also, there are no restrictions in respect to passing 
parameters. As long as you have access to an entity, you can pass it to someone 
else; that's your responsibility.

>  The compiler messages don’t really help to figure out what the rules are, if 
> I have this

Swift error messages are still confusing sometimes. But in this case the 
compiler is pretty explicit about the problem.

> The last one I don’t get at all, why should making the class private stop the 
> methods being implicitly @objc? 

That's explained in "Using Swift with Cocoa and Objective-C":

"The compiler does not automatically insert the @objc attribute for 
declarations marked with the private access-level modifier."

It is not explained why, but I suspect it's because @objc adds the declaration 
to the dynamic runtime and makes it introspectable. If you explicitly mark 
something as private, you might not want that. (And there's no @not-objc 
modifier.) 


Andreas
___

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

Re: Swift - internal class conforming to public protocol

[Roland King]

> On 25 Nov 2015, at 00:59, Andreas Mayer  wrote:
> 
> 
>> Am 24.11.2015 um 15:10 schrieb Roland King :
>> 
>> in this class, centralManagerDidUpdateState() is an internal function 
>> however the compiler is happy that the class satisfies 
>> CBCentralManagerDelegate even though that protocol is public and 
>> centralManagerDidUpdateState() is also public. How can this be, how can an 
>> internal function make a class conform to a public method on a public 
>> protocol. That function is required in the protocol. 
> 
> Maybe I'm misunderstanding something, but I'm not sure why you think this 
> should be a problem?
> 
> You can always make things more restrictive.
> 
> It's the other way around that is not allowed. Say, using an internal 
> protocol to define a public class - that wouldn't work, since the user of the 
> class might not have access to the internal protocol.


ok to this and Quincey’s email also. I can see the argument about making things 
more restrictive, not less. In that case then, 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)? 

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.  

The compiler messages don’t really help to figure out what the rules are, if I 
have this

 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)

if access specifier is internal I get nothing, all compiles fine

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? 






___

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

Re: Swift - internal class conforming to public protocol

[Quincey Morris]

On Nov 24, 2015, at 23:13 , Marco S Hyman  wrote:

> As I read that adopting a public protocol requires the methods that implement 
> the protocol to be public (but only those methods).

As I said earlier, this isn’t true any more. (I think this change was made in 
the Swift that was delivered with Xcode 7.0 beta 3, which was released in 
July.) The following compiles in a playground in Xcode 7.1.1:

> public protocol XP
> {
>   func implementMe ();
> }
> 
> internal class YC: XP
> {
>   internal func implementMe () {}
> }


On Nov 24, 2015, at 22:54 , Andreas Mayer  wrote:

> Also, there are no restrictions in respect to passing parameters. As long as 
> you have access to an entity, you can pass it to someone else; that's your 
> responsibility.

Yes, but if you can’t access the entity’s type declaration (because it’s 
declared internal or private in another module), then you can't get access to 
the entity with its actual type. You can only access it via a compatible type 
that’s public (i.e. a public protocol or superclass), and then you’ll only be 
able to see the public methods.

> That's explained in "Using Swift with Cocoa and Objective-C":
> 
> "The compiler does not automatically insert the @objc attribute for 
> declarations marked with the private access-level modifier.”

That can’t be the full explanation, because the other private method doesn’t 
produce an error, Roland said.



___

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

Re: Swift - internal class conforming to public protocol

[Marco S Hyman]

>> 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)?
> 
> If you declare it internal it's internal. Adopting a public protocol doesn't 
> change that.

There is a specific note in the Swift book:

“If you define a public protocol, the protocol’s requirements require a public 
access level for those requirements when they are implemented. This behavior is 
different from other types, where a public type definition implies an access 
level of internal for the type’s members.”

Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.1 
Prerelease).” iBooks. 

As I read that adopting a public protocol requires the methods that implement 
the protocol to be public (but only those methods).
___

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

Re: Swift - internal class conforming to public protocol

[Quincey Morris]

On Nov 24, 2015, at 06:10 , Roland King  wrote:
> 
> How can this be, how can an internal function make a class conform to a 
> public method on a public protocol.

IIRC, until fairly recently (i.e. WWDC 2015 or one of the later Xcode 
releases), it worked as your intuition tells you — it wasn’t allowed.

Thankfully, though, this is now fixed, and even a private class can adopt a 
public protocol, and the adoption is private (meaning that the required methods 
can be private).

I believe you have to consider 3 factors: 

— the access level of the protocol declaration (which is a limit on the 
*visibility* of the protocol to adopters); 
— the access level at which the protocol is *adopted* by a class (which is the 
class access level, constrained to *at most* the protocol visibility access 
level); 
— the access level of the protocol methods implemented in the class, 
constrained to *at least* the adoption access level. 

(I’m not sure I have that exactly right, but it’s something like that.)

So, this works:

> private protocol XP
> {
>   func implementMe ();
> }
> 
> public class YC: XP
> {
>   private func implementMe () {}
> }

and so does this:

> private protocol XP
> {
>   func implementMe ();
> }
> 
> public class YC: XP
> {
>   public func implementMe () {}
> }


but this does not:

> public protocol XP
> {
>   func implementMe ();
> }
> 
> public class YC: XP
> {
>   private func implementMe () {}
> }

Unfortunately, complicated as this is, it’s still not enough. There’s also a 
need (IMO) for a public/internal class to be able to adopt a public/internal 
protocol privately. My example is a class that needs to be public for other 
reasons, and which adopts a delegate protocol that happens to be public, but 
doesn’t want to advertise to its clients that it conforms. (It doesn’t want 
clients maliciously invoking delegate methods. Only the object that it’s a 
delegate for should know) This can’t be done, but it would need something like 
this:

> public protocol XP
> {
>   func implementMe ();
> }
> 
> public class YC: private XP // <<— not currently valid
> {
>   private func implementMe () {}
> }

___

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

Re: Swift - internal class conforming to public protocol

[Andreas Mayer]

> Am 24.11.2015 um 15:10 schrieb Roland King :
> 
> in this class, centralManagerDidUpdateState() is an internal function however 
> the compiler is happy that the class satisfies CBCentralManagerDelegate even 
> though that protocol is public and centralManagerDidUpdateState() is also 
> public. How can this be, how can an internal function make a class conform to 
> a public method on a public protocol. That function is required in the 
> protocol. 

Maybe I'm misunderstanding something, but I'm not sure why you think this 
should be a problem?

You can always make things more restrictive.

It's the other way around that is not allowed. Say, using an internal protocol 
to define a public class - that wouldn't work, since the user of the class 
might not have access to the internal protocol.

The Swift book says:


Guiding Principle of Access Levels

Access levels in Swift follow an overall guiding principle: No entity can be 
defined in terms of another entity that has a lower (more restrictive) access 
level.


(I had to find the online version, since iBooks doesn't let me copy from the 
Swift book. WTF?!)

> How can this be, how can an internal function make a class conform to a 
> public method on a public protocol. That function is required in the 
> protocol. 

It's fine because the class itself is internal. So there's no problem with 
centralManagerDidUpdateState() being internal too.

As you found out, that changes, when you make the class public. Because now the 
user of the class might not be able to access centralManagerDidUpdateState() if 
it's internal.

Disclaimer: I'm still learning Swift myself, so I might have everything totally 
wrong. ;)


Andreas


___

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

Swift - internal class conforming to public protocol

[Roland King]

I have the following class, it was internal by default, but I’ve made it so 
explicitly for the purpose of the question. 

internal class ControllerBTLEListener: NSObject, CBCentralManagerDelegate
{
// the queue for all our operations
static let queue : dispatch_queue_t = dispatch_queue_create( "BTLE 
queue", DISPATCH_QUEUE_SERIAL )

// implementation of CBCentralManagerDelegate
func centralManagerDidUpdateState(central: CBCentralManager)
{

}
}


in this class, centralManagerDidUpdateState() is an internal function however 
the compiler is happy that the class satisfies CBCentralManagerDelegate even 
though that protocol is public and centralManagerDidUpdateState() is also 
public. How can this be, how can an internal function make a class conform to a 
public method on a public protocol. That function is required in the protocol. 

It gets stranger. If I change the class from internal to public the I’m 
required to mark centralManagerDidUpdateState() as public (it would be internal 
by default) to conform to the protocol so the compiler seems to know that 
function has to be public, but is allowing it to be internal if the class 
itself is internal. 

Compiler bug or more lack of understanding here? 
___

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