Add NSNotificationObserver implementation

[JiriTrecak]

First of all, awesome job with releasing swift (and thanks for stealing our sleep..)

I'd like to help with creation of some of the base classes, so I started with NSNotificationCenter; I created underlaying observer object for storage. If that can be accepted, I will write the rest of the implementation.

Little offtopic, but would be great to have answer: What is optimal size of the pull request(s)? Obviously, this is very broad topic, but in general - in swift guide, smaller increments are encouraged, but definition of "smaller" can vary a lot when working on something like this.

[phausler]

To clarify a bit, Foundation has a bit of a special case for the "small pull request" thing. Ideally commits should be testable and discrete thoughts (that can mean 2 lines to 2000 lines, but remember more code is harder to review); works-in-progress might not always be the best route since they are sometimes either not fully testable or there is a requirement that someone might have to pick it up and finish it.

To your code: (and this is something we should probably go in and annotate a bit further) NSNotificationCenter is something we are actually considering some alterations for the swift side. If you note the registration of observers is completely elided. Usually if a method with a selector in the arguments is missing and has no counterpart it means we are still considering what the right API will be. This of course has some severe ramifications when it comes to the Darwin targets; in that part of this project is to help shape what Foundation looks like and acts like in swift in addition to allowing a common cross platform interface on both Darwin and Linux (and now evidently FreeBSD? yay pull requests!) environments.

I would have to confirm with the other engineer that was working with the swift interface proposal for NSNotificationCenter. The tricky part is that we will need to make this work for both notifications posted from CF, and Objective-C sources as well as making a clean interface for registering and posting notifications in Swift.

tl;dr, some areas we will pay extra close attention to because it will eventually mean things that will creep in on both the objective-c and swift interfaces on Mac OS X, iOS, etc.

[JiriTrecak]

So that basically means wait and see what you will bring, right :)

This is 'problem' with lot of classes (like NSOperation etc.), where the underlaying functionality can be so deep, that people from "outside" have no chance of creating it. The second problem as you pointed out is achieving proper functionality within Swift / ObjC / CF scope - that is also something that needs to be defined very well. Personally, I think this one could be resolved by doing swift-first integration and then iterate further on where it is needed, the question is if the amount of changes needed would not be too much and also, if that is approach that you are accepting. Probably would have to be reviewed on case-to-case basis.

While I understand that the development can and should be governed primarily by Apple devs, I also strongly believe that there is many people who would be willing to do contribute significant portions of code (sign me up), significantly reducing the time needed to develop such things at the end.

As for the notification center, I actually thought that was design decision to remove them (probably because of Selector usage), thanks for clarifying that it can also mean "work in progress" :)

tl;dr,

• Would it be possible to actually make concrete requests / descriptions of what the implementation should be, some major points what is expected, for cases like this?

Thanks for your effort!

[parkera]

We are open to accepting an implementation here. What we'll need is something that has a bit more functionality and associated tests, so we can verify that it's working. I'm going to go ahead and close this one, but please get in contact with us on the mailing lists and let's work out how to move forward with this .