Swift enums and NSNotificationCenter

2015-08-05 Thread Rick Mann
I'd like to be able to write code like this:

enum MyNotifications : String {
case Note1  = "note1"
case Note2  = "note2"
}

let nc = NSNotificationCenter.defaultCenter()
nc.postNotificationName(MyNotifications.Note1, nil)

But Swift (2.0) doesn't let me do that. Is it possible to write an extension 
method to NSNotificationCenter that accepts "any enum derived from String" (or 
that's convertible to String, or something like that)? e.g.:

func postNotification(inName : enum:String)

I tried doing this: http://pastebin.com/kXLEHu8f

But it gets multiple errors, as you can see.

Is there an elegant way to do this? Seems counter-intuitive that I can't pass a 
derived enum in place of an ancestral type.

-- 
Rick Mann
rm...@latencyzero.com



___

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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
On Aug 5, 2015, at 6:22 PM, Rick Mann  wrote:
> 
> I'd like to be able to write code like this:
> 
> enum MyNotifications : String {
>case Note1 = "note1"
>case Note2 = "note2"
> }
> 
> let nc = NSNotificationCenter.defaultCenter()
> nc.postNotificationName(MyNotifications.Note1, nil)
> 
> But Swift (2.0) doesn't let me do that. Is it possible to write an extension 
> method to NSNotificationCenter that accepts "any enum derived from String" 
> (or that's convertible to String, or something like that)? e.g.:
> 
>func postNotification(inName : enum:String)
> 
> I tried doing this: http://pastebin.com/kXLEHu8f 
> 
> 
> But it gets multiple errors, as you can see.
> 
> Is there an elegant way to do this? Seems counter-intuitive that I can't pass 
> a derived enum in place of an ancestral type.

AFAIK there’s no way to do exactly what you’re asking for, but you could put a 
post() method on the enum itself.

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann

> On Aug 5, 2015, at 16:38 , Charles Srstka  wrote:
> 
> On Aug 5, 2015, at 6:22 PM, Rick Mann  wrote:
>> 
>> I'd like to be able to write code like this:
>> 
>> enum MyNotifications : String {
>>case Note1= "note1"
>>case Note2= "note2"
>> }
>> 
>> let nc = NSNotificationCenter.defaultCenter()
>> nc.postNotificationName(MyNotifications.Note1, nil)
>> 
>> But Swift (2.0) doesn't let me do that. Is it possible to write an extension 
>> method to NSNotificationCenter that accepts "any enum derived from String" 
>> (or that's convertible to String, or something like that)? e.g.:
>> 
>>func postNotification(inName : enum:String)
>> 
>> I tried doing this: http://pastebin.com/kXLEHu8f
>> 
>> But it gets multiple errors, as you can see.
>> 
>> Is there an elegant way to do this? Seems counter-intuitive that I can't 
>> pass a derived enum in place of an ancestral type.
> 
> AFAIK there’s no way to do exactly what you’re asking for, but you could put 
> a post() method on the enum itself.

Well, that kinda works, for a single enum, but I can't derive an enum from that 
because I run into this when I subclass an enum.

playground28.swift:26:16: error: raw type 'Notes' is not convertible from any 
literal
enum MyNotes : Notes
   ^
playground28.swift:26:6: error: type 'MyNotes' does not conform to protocol 
'RawRepresentable'
enum MyNotes : Notes
 ^
Swift.RawRepresentable:11:13: note: protocol requires nested type 'RawValue'
  typealias RawValue



-- 
Rick Mann
rm...@latencyzero.com



___

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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
On Aug 5, 2015, at 6:45 PM, Rick Mann  wrote:
> 
>> 
>> On Aug 5, 2015, at 16:38 , Charles Srstka > > wrote:
>> 
>> On Aug 5, 2015, at 6:22 PM, Rick Mann  wrote:
>>> 
>>> I'd like to be able to write code like this:
>>> 
>>> enum MyNotifications : String {
>>>   case Note1= "note1"
>>>   case Note2= "note2"
>>> }
>>> 
>>> let nc = NSNotificationCenter.defaultCenter()
>>> nc.postNotificationName(MyNotifications.Note1, nil)
>>> 
>>> But Swift (2.0) doesn't let me do that. Is it possible to write an 
>>> extension method to NSNotificationCenter that accepts "any enum derived 
>>> from String" (or that's convertible to String, or something like that)? 
>>> e.g.:
>>> 
>>>   func postNotification(inName : enum:String)
>>> 
>>> I tried doing this: http://pastebin.com/kXLEHu8f
>>> 
>>> But it gets multiple errors, as you can see.
>>> 
>>> Is there an elegant way to do this? Seems counter-intuitive that I can't 
>>> pass a derived enum in place of an ancestral type.
>> 
>> AFAIK there’s no way to do exactly what you’re asking for, but you could put 
>> a post() method on the enum itself.
> 
> Well, that kinda works, for a single enum, but I can't derive an enum from 
> that because I run into this when I subclass an enum.
> 
> playground28.swift:26:16: error: raw type 'Notes' is not convertible from any 
> literal
> enum MyNotes : Notes
>   ^
> playground28.swift:26:6: error: type 'MyNotes' does not conform to protocol 
> 'RawRepresentable'
> enum MyNotes : Notes
> ^
> Swift.RawRepresentable:11:13: note: protocol requires nested type 'RawValue'
>  typealias RawValue

I get that error any time I try to subclass *any* enum. I don’t think enums are 
supposed to be subclassable.

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann

> On Aug 5, 2015, at 16:57 , Charles Srstka  wrote:
> 
> I get that error any time I try to subclass *any* enum. I don’t think enums 
> are supposed to be subclassable.

Guess I'll submit a bug. Seems perfectly reasonable to do.


-- 
Rick Mann
rm...@latencyzero.com



___

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 enums and NSNotificationCenter

2015-08-05 Thread Jens Alfke

> On Aug 5, 2015, at 5:00 PM, Rick Mann  wrote:
> 
>> On Aug 5, 2015, at 16:57 , Charles Srstka > > wrote:
>> 
>> I get that error any time I try to subclass *any* enum. I don’t think enums 
>> are supposed to be subclassable.
> 
> Guess I'll submit a bug. Seems perfectly reasonable to do.

It’s part of the language design that only classes support inheritance, not 
structs or enums. 

Basically, subclassing pass-by-value types is problematic. For example, what 
happens when you assign a SubclassStruct value to a variable of type 
BaseStruct, or pass it to a function parameter of type BaseStruct? Do the extra 
instance variables get chopped off when it’s copied? What happens if you call a 
BaseStruct method that was overridden in SubclassStruct?

C++ lets you do this, but it can lead to really nasty problems, so style guides 
like Effective C++ recommend avoiding it.

—Jens
___

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: AnyObject and protocols

2015-08-05 Thread Charles Srstka
> On Aug 4, 2015, at 6:23 PM, Rick Mann  wrote:
> 
>> On Aug 4, 2015, at 16:22 , Quincey Morris 
>>  wrote:
>> 
>> On Aug 4, 2015, at 15:58 , Rick Mann  wrote:
>>> 
>>> I'm curious why, and what the right approach might be?
>> 
>> As to why, the problem is that instances of a type conforming to a protocol 
>> aren’t necessarily objects. If you want them to be, try declaring your 
>> protocol like this:
>> 
>>  protocol P: class {
>>  …
>>  }
> 
> Awesome, thanks!

Sorry for the delay; it took me a while to figure out why the line of code with 
addObserverForName was giving wonderfully helpful errors like “‘String’ is not 
convertible to ‘StringLiteralConvertible’” (grumble grumble).

Anyway, what you want may be possible via a protocol extension:

import Foundation

protocol PostableEnum {
func post()
var rawValue: String { get }
}

extension PostableEnum {
func post() {

NSNotificationCenter.defaultCenter().postNotificationName(self.rawValue, 
object: nil)
}
}

enum SomeEnum : String, PostableEnum {
case Foo = "Foo"
}

let someEnum = SomeEnum.Foo

let foo = NSObject()

let observer = NSNotificationCenter.defaultCenter().addObserverForName("Foo", 
object: nil, queue: nil) { _ in
print("notification received")
}

someEnum.post()

CFRunLoopRun()

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: AnyObject and protocols

2015-08-05 Thread Charles Srstka
I’m just on fire today, aren’t I? Posted this on the wrong thread. Sorry for 
the noise.

Charles

> On Aug 5, 2015, at 7:17 PM, Charles Srstka  wrote:
> 
>> On Aug 4, 2015, at 6:23 PM, Rick Mann  wrote:
>> 
>>> On Aug 4, 2015, at 16:22 , Quincey Morris 
>>>  wrote:
>>> 
>>> On Aug 4, 2015, at 15:58 , Rick Mann  wrote:
 
 I'm curious why, and what the right approach might be?
>>> 
>>> As to why, the problem is that instances of a type conforming to a protocol 
>>> aren’t necessarily objects. If you want them to be, try declaring your 
>>> protocol like this:
>>> 
>>> protocol P: class {
>>> …
>>> }
>> 
>> Awesome, thanks!
> 
> Sorry for the delay; it took me a while to figure out why the line of code 
> with addObserverForName was giving wonderfully helpful errors like “‘String’ 
> is not convertible to ‘StringLiteralConvertible’” (grumble grumble).
> 
> Anyway, what you want may be possible via a protocol extension:
> 
> import Foundation
> 
> protocol PostableEnum {
>func post()
>var rawValue: String { get }
> }
> 
> extension PostableEnum {
>func post() {
>
> NSNotificationCenter.defaultCenter().postNotificationName(self.rawValue, 
> object: nil)
>}
> }
> 
> enum SomeEnum : String, PostableEnum {
>case Foo = "Foo"
> }
> 
> let someEnum = SomeEnum.Foo
> 
> let foo = NSObject()
> 
> let observer = NSNotificationCenter.defaultCenter().addObserverForName("Foo", 
> object: nil, queue: nil) { _ in
>print("notification received")
> }
> 
> someEnum.post()
> 
> CFRunLoopRun()
> 
> 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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
> On Aug 5, 2015, at 7:00 PM, Rick Mann  wrote:
> 
>> 
>> On Aug 5, 2015, at 16:57 , Charles Srstka > > wrote:
>> 
>> I get that error any time I try to subclass *any* enum. I don’t think enums 
>> are supposed to be subclassable.
> 
> Guess I'll submit a bug. Seems perfectly reasonable to do.

Sorry for the delay; it took me a while to figure out why the line of code with 
addObserverForName was giving wonderfully helpful errors like “‘String’ is not 
convertible to ‘StringLiteralConvertible’” (grumble grumble).

Anyway, what you want may be possible via a protocol extension:

import Foundation

protocol PostableEnum {
   func post()
   var rawValue: String { get }
}

extension PostableEnum {
   func post() {
   NSNotificationCenter.defaultCenter().postNotificationName(self.rawValue, 
object: nil)
   }
}

enum SomeEnum : String, PostableEnum {
   case Foo = "Foo"
}

let someEnum = SomeEnum.Foo

let foo = NSObject()

let observer = NSNotificationCenter.defaultCenter().addObserverForName("Foo", 
object: nil, queue: nil) { _ in
   print("notification received")
}

someEnum.post()

CFRunLoopRun()

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann

> On Aug 5, 2015, at 17:14 , Jens Alfke  wrote:
> 
> 
>> On Aug 5, 2015, at 5:00 PM, Rick Mann  wrote:
>> 
>>> On Aug 5, 2015, at 16:57 , Charles Srstka  wrote:
>>> 
>>> I get that error any time I try to subclass *any* enum. I don’t think enums 
>>> are supposed to be subclassable.
>> 
>> Guess I'll submit a bug. Seems perfectly reasonable to do.
> 
> It’s part of the language design that only classes support inheritance, not 
> structs or enums. 
> 
> Basically, subclassing pass-by-value types is problematic. For example, what 
> happens when you assign a SubclassStruct value to a variable of type 
> BaseStruct, or pass it to a function parameter of type BaseStruct? Do the 
> extra instance variables get chopped off when it’s copied? What happens if 
> you call a BaseStruct method that was overridden in SubclassStruct?
> 
> C++ lets you do this, but it can lead to really nasty problems, so style 
> guides like Effective C++ recommend avoiding it.

But for extending the cases in an enum, it seems pretty nice.

-- 
Rick Mann
rm...@latencyzero.com



___

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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
> On Aug 5, 2015, at 7:18 PM, Charles Srstka  wrote:
> 
> let foo = NSObject()

This line should have been deleted, sorry; it was part of my debugging to try 
to figure out why the heck I was getting that error, and I forgot to delete it.

I should also have posted the console output from running the program, but I 
bet you can guess what it is:

notification received

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann
Thanks, I'll see what I can make of that. Still not quite as nice as being able 
to pass an enum to an NSNotificationCenter extension method, but partway there.

Would it make sense for Swift to just let you add method implementations to 
protocols (perhaps as a shortcut to the protocol-extension technique you used)?

> On Aug 5, 2015, at 17:18 , Charles Srstka  wrote:
> 
>> On Aug 5, 2015, at 7:00 PM, Rick Mann  wrote:
>> 
>>> 
>>> On Aug 5, 2015, at 16:57 , Charles Srstka  wrote:
>>> 
>>> I get that error any time I try to subclass *any* enum. I don’t think enums 
>>> are supposed to be subclassable.
>> 
>> Guess I'll submit a bug. Seems perfectly reasonable to do.
> 
> Sorry for the delay; it took me a while to figure out why the line of code 
> with addObserverForName was giving wonderfully helpful errors like “‘String’ 
> is not convertible to ‘StringLiteralConvertible’” (grumble grumble).
> 
> Anyway, what you want may be possible via a protocol extension:
> 
> import Foundation
> 
> protocol PostableEnum {
>func post()
>var rawValue: String { get }
> }
> 
> extension PostableEnum {
>func post() {
>
> NSNotificationCenter.defaultCenter().postNotificationName(self.rawValue, 
> object: nil)
>}
> }
> 
> enum SomeEnum : String, PostableEnum {
>case Foo = "Foo"
> }
> 
> let someEnum = SomeEnum.Foo
> 
> let foo = NSObject()
> 
> let observer = NSNotificationCenter.defaultCenter().addObserverForName("Foo", 
> object: nil, queue: nil) { _ in
>print("notification received")
> }
> 
> someEnum.post()
> 
> CFRunLoopRun()
> 
> Charles
> 


-- 
Rick Mann
rm...@latencyzero.com



___

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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
On Aug 5, 2015, at 7:21 PM, Rick Mann  wrote:
> 
> Would it make sense for Swift to just let you add method implementations to 
> protocols (perhaps as a shortcut to the protocol-extension technique you 
> used)?

That’s what a protocol extension *is*.

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann

> On Aug 5, 2015, at 17:40 , Charles Srstka  wrote:
> 
> On Aug 5, 2015, at 7:21 PM, Rick Mann  wrote:
>> 
>> Would it make sense for Swift to just let you add method implementations to 
>> protocols (perhaps as a shortcut to the protocol-extension technique you 
>> used)?
> 
> That’s what a protocol extension *is*.

No, I meant syntactically to the protocol. I'm not saying get rid of protocol 
extensions, but why not be able to also do this?

protocol MyProtocol {
func myFunc()
{
some stuff
}
}

This should be equivalent to

protocol MyProtocol {
}

extension MyProtocol {
func myFunc()
{
some stuff
}
}


-- 
Rick Mann
rm...@latencyzero.com



___

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

Improve performance of data structure saved to disk

2015-08-05 Thread Juanjo Conti
Hi there!

At the moment I'm using Keyed-Archiving, but after detecting performance
issues and read I'm changing to Core-Data.

The data structure is a NSMutableDictionary in which keys are instantness
of a custom class CookieKey and values and instances of NSHTTPCookie.
CookieKey has 3 string properties (domain, path and name) and implements
NSCoding protocol.

In the new implementation CookieKey will extend NSManagedObject and have
the 3 string properties + a NSData one called cookie. And I'll work with a
NSMutableArray.

Is it a good idea? Another approach to use Core Data and improve
performance?

Thanks in advance!

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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 enums and NSNotificationCenter

2015-08-05 Thread Quincey Morris
On Aug 5, 2015, at 19:48 , Rick Mann  wrote:
> 
> why not be able to also do this?
> 
> protocol MyProtocol {
>func myFunc()
>{
>some stuff
>}
> }

Chris Lattner has said (in the developer forums) that this seems like an 
obvious future step for protocols, so perhaps it will come to be, sometime.
___

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: Improve performance of data structure saved to disk

2015-08-05 Thread Quincey Morris
On Aug 5, 2015, at 20:17 , Juanjo Conti  wrote:
> 
> At the moment I'm using Keyed-Archiving, but after detecting performance
> issues and read I'm changing to Core-Data.

What quantity of entries/records are you talking about here? It’s not going to 
make a big difference to performance (as opposed to a smaller, custom solution 
that doesn’t involved archiving, if that is in fact the bottleneck) unless you 
have tens of thousands of records to store.

IMO, Core Data is a terribly painful technology that will make you very, very 
miserable, not to mention adding many months to your project.

As an alternative, if your use case is really a kind of database, you could try 
using something like sqlite or couchDB (whatever it’s called now, I’m sure Jens 
would be happy to fill you in). If it’s not, write a custom data file and be 
done with it.

I don’t know for sure, but my impression is that the things that are slow in 
archiving are:

— Following links in a non-hierarchical object graph.

— Uniquing values stored as objects, such as NSString and NSNumber.

___

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 enums and NSNotificationCenter

2015-08-05 Thread Charles Srstka
> On Aug 5, 2015, at 9:48 PM, Rick Mann  wrote:
> 
>> 
>> On Aug 5, 2015, at 17:40 , Charles Srstka > > wrote:
>> 
>> On Aug 5, 2015, at 7:21 PM, Rick Mann > > wrote:
>>> 
>>> Would it make sense for Swift to just let you add method implementations to 
>>> protocols (perhaps as a shortcut to the protocol-extension technique you 
>>> used)?
>> 
>> That’s what a protocol extension *is*.
> 
> No, I meant syntactically to the protocol. I'm not saying get rid of protocol 
> extensions, but why not be able to also do this?
> 
> protocol MyProtocol {
>func myFunc()
>{
>some stuff
>}
> }
> 
> This should be equivalent to
> 
> protocol MyProtocol {
> }
> 
> extension MyProtocol {
>func myFunc()
>{
>some stuff
>}
> }

Ah, sorry I misunderstood. Yeah, this does seem to be a bit of a no-brainer.

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 enums and NSNotificationCenter

2015-08-05 Thread Rick Mann

> On Aug 5, 2015, at 20:53 , Charles Srstka  wrote:
> 
> Ah, sorry I misunderstood. Yeah, this does seem to be a bit of a no-brainer.

No worries, and I agree. Based on Quincey's email, I guess we'll see it 
eventually.

Thanks!

-- 
Rick Mann
rm...@latencyzero.com



___

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