Initial implementation of NSNumberFormatter.

[chrisfsampaio]

• Added implementation for attributes.
• Added tests for initial implementation.
• Updated implementation status documentation.

[cullenbmacdonald]

another option is to drop the internal var here and use willSet

[chrisfsampaio]

That would be nice!
But I think that on a next step we should do something like this:

    internal var _numberStyle: NSNumberFormatterStyle = .NoStyle
    public var numberStyle: NSNumberFormatterStyle {
        get {
            let rawValue = CFNumberFormatterGetStyle(_cfObject).rawValue
            _numberStyle = NSNumberFormatterStyle(rawValue: UInt(rawValue))!
            return _numberStyle
        }

        set {
            _reset()
            _numberStyle = newValue
        }
    }

And then we would be sure that both our object and the internal CoreFoundation formatter are in sync, which currently isn't happening. We could also take leverage of CoreFoundation number formatter default values.

I really dislike the interval vars too, but I can't think of any other option. 😞
Do you see any other way that allows us to keep both worlds in sync?

[chrisfsampaio]

Done, added the missing tests.
In terms of implementation, I guess this is enough for this PR (taking incremental development into account).
Please, let me know if I need to change anything else.

[parkera]

Two things here:

1. We use the _cfObject method for types which are bridged. I think that the CFNumberFormatter/NSNumberFormatter relationship could instead be 'has-a', as in NSNumberFormatter has a CFNumberFormatterRef. This means we don't have to worry about things like matching up ivar layout. So I would call this internal var something besides _cfObject to avoid confusion.
2. Whatever we call the internal var backing the internal var, it'd be nice if it was not the same name with just an additional underscore... I feel like it's too easy to mess that up and use it accidentally somewhere in the rest of the class.

[chrisfsampaio]

👍 ef329ed

Regarding (2), what do you think of making it private? If we need access to the internal formatter somewhere else in the lib, one still could use the _cfFormatter.

[parkera]

I think it's probably the case that we want the _cfFormatter to only be used within NSDateFormatter itself; other internal-to-library clients should still use the public API (preferred) or a private swift method (if required for some reason).

[chrisfsampaio]

Makes sense, I made both of them private then.

[parkera]

I'm going to review some more later but I think this is a great start.

[chrisfsampaio]

I'm going to review some more later but I think this is a great start.

Nice! 👍

[parkera]

Let's go ahead and rebase this and squash into a single commit for merge. Thanks!

[chrisfsampaio]

Let's go ahead and rebase this and squash into a single commit for merge. Thanks!

👍 Done! Thanks!

I've also reordered the test case to be alphabetically sorted in favor of #111.

[chrisfsampaio]

I've also updated the status page to reflect the changes made on this PR.

[parkera]

Hm, getting 5 test failures, all in the currency paths, but only on Linux.

[parkera]

Ah, the currency stuff is only available on ICU 5.5 or later.