NSDecimal & NSDecimalNumber


(Florian) #1

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian


(Philippe Hausler) #2

NSDecimalNumber is mostly just a simple object wrapper for NSDecimal that interoperates with NSNumber so that seems like a pretty sensible approach ordering.

Since the goal of the swift-corelibs-foundation is to as closely match the current APIs of Foundation as possible (exclusions have been made where it just isn’t possible); so I would say that option 1 would be the more appropriate way to start off.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NumbersandValues/Articles/DecimalNumbers.html might be a decent place to get a little bit of background; my suggestion however would be to write some really good unit tests to verify it’s behavior.

Eventually we would like to archive these things so keeping it the same structure is probably a good idea.

That all being said - NSDecimal itself seems reasonably suitable for a re-look from a swift perspective. NSDecimalAdd, NSDecimalSubtract etc all really would be more wonderful with operators and some instance methods/properties would be really useful as well. The implementation of NSDecimal and these additions are two different pieces and should be considered separately as well. In that any change that we make to diverge from usage immediately will not be directly usable on Mac OS X/iOS since we will have to work that into the foundation overlay and/or make modifications to the Foundation implementation for supporting any changes like that.

So in short: #1 is the suggested route for a pull request onto Foundation and #2 is a better route for a proposal for swift-evolution (specifically targeted at Foundation).

···

On Dec 11, 2015, at 4:32 AM, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Matthew Johnson) #3

This thread is related to the thread I started last night about Foundation and value types.

Ideally all Foundation types that are already structs would expose a more Swifty interface and those that are naturally value types but currently implemented as classes would be bridged and exposed in Swift as value types.

Responses last night seem to indicate at least some appetite for doing this if an acceptable bridging strategy can be identified even though it increases scope a bit as it is not directly related to portability.

I would be extremely pleased if we are able to pull this off as it should be possible to design value types by composing Date, URL, Decimal, etc without needing to create our own value type wrappers for them.

Matthew

···

Sent from my iPhone

On Dec 11, 2015, at 9:45 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

NSDecimalNumber is mostly just a simple object wrapper for NSDecimal that interoperates with NSNumber so that seems like a pretty sensible approach ordering.

Since the goal of the swift-corelibs-foundation is to as closely match the current APIs of Foundation as possible (exclusions have been made where it just isn’t possible); so I would say that option 1 would be the more appropriate way to start off.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NumbersandValues/Articles/DecimalNumbers.html might be a decent place to get a little bit of background; my suggestion however would be to write some really good unit tests to verify it’s behavior.

Eventually we would like to archive these things so keeping it the same structure is probably a good idea.

That all being said - NSDecimal itself seems reasonably suitable for a re-look from a swift perspective. NSDecimalAdd, NSDecimalSubtract etc all really would be more wonderful with operators and some instance methods/properties would be really useful as well. The implementation of NSDecimal and these additions are two different pieces and should be considered separately as well. In that any change that we make to diverge from usage immediately will not be directly usable on Mac OS X/iOS since we will have to work that into the foundation overlay and/or make modifications to the Foundation implementation for supporting any changes like that.

So in short: #1 is the suggested route for a pull request onto Foundation and #2 is a better route for a proposal for swift-evolution (specifically targeted at Foundation).

On Dec 11, 2015, at 4:32 AM, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Tony Parker) #4

Hi Dan, Florian,

I agree with Philippe that NSDecimal is a particularly troublesome area in terms of how poorly the API is imported into Swift.

Since NSDecimal is already a value type, it may be possible to do something better here ourselves without worrying about the bridging problem. It would be an API change, however, so we should follow the swift-evolution process.

NSDecimalNumber would be more complicated, since it’s a class (and furthermore, a subclass of NSNumber).

I’d be really interested in working on a Swift decimal number type. I’ve done some work on this for a Money type here: https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal

I agree that it’s best to start with NSDecimal, and that approach 2 would offer the most flexibility.

I have a few other thoughts regarding the number behaviors.

NSDecimal’s functions accept rounding mode parameters and return NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior parameter and throws NSExceptions. I’m not really sure what the reason for this discrepancy is and should a new Swift NSDecimal use NSDecimalNumberBehavior, but maintain backwards compatibility with default behaviors and defined rounding mode?

Our primary goal is API compatibility across platforms. It would be really unfortunate if a client of Foundation had to #ifdef their code to account for a platform difference.

That’s not to say we can’t improve things (as we do with every release), but compatibility requirements are a fact of life for a low level library like ours. Our clients appreciate it. =)

Also, should a Swift NSDecimal continues with raising NSException, or adopt Swift style error handling? I don’t think we would want to introduce try/throw/catch semantics into the publicly exposed methods - but we could have an internal API layer which does. Backwards compatible functions would then have to convert between Swift ErrorType and NSException or NSCalculationError.

Anywhere that Darwin Foundation raises an NSException, we are replacing with fatalError, precondition, or similar. The root cause of either is the same (a programmer error). The try/catch/throws mechanism is for errors that we may want to present to a user at some point.

Hope this helps,
- Tony

···

On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Cheers,
Dan

p.s. in the linked project, I made a DecimalNumberType protocol generic over the Behavior, which I’m not entire sure was a good decision or not.

On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Dan Thorpe) #5

I’d be really interested in working on a Swift decimal number type. I’ve done some work on this for a Money type here: https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal

I agree that it’s best to start with NSDecimal, and that approach 2 would offer the most flexibility.

I have a few other thoughts regarding the number behaviors.

NSDecimal’s functions accept rounding mode parameters and return NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior parameter and throws NSExceptions. I’m not really sure what the reason for this discrepancy is and should a new Swift NSDecimal use NSDecimalNumberBehavior, but maintain backwards compatibility with default behaviors and defined rounding mode?

Also, should a Swift NSDecimal continues with raising NSException, or adopt Swift style error handling? I don’t think we would want to introduce try/throw/catch semantics into the publicly exposed methods - but we could have an internal API layer which does. Backwards compatible functions would then have to convert between Swift ErrorType and NSException or NSCalculationError.

Cheers,
Dan

p.s. in the linked project, I made a DecimalNumberType protocol generic over the Behavior, which I’m not entire sure was a good decision or not.

···

On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Dan Thorpe) #6

Thanks for the clarification Tony - and for reminding me of the primary goal r.e. API compatibility. :slight_smile:

This may be better suited to swift-evolution or users list, but regarding fatalError do you have any techniques for testing this behavior? I was thinking about an internal try/throw/ layer (which would then be caught and trampolined to fatalError for the public APIs) so that it would be possible to write unit tests for the edge cases where there is a calculation error.

Cheers,
Dan

···

On 11 Dec 2015, at 19:00, Tony Parker <anthony.parker@apple.com> wrote:

Hi Dan, Florian,

I agree with Philippe that NSDecimal is a particularly troublesome area in terms of how poorly the API is imported into Swift.

Since NSDecimal is already a value type, it may be possible to do something better here ourselves without worrying about the bridging problem. It would be an API change, however, so we should follow the swift-evolution process.

NSDecimalNumber would be more complicated, since it’s a class (and furthermore, a subclass of NSNumber).

On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

I’d be really interested in working on a Swift decimal number type. I’ve done some work on this for a Money type here: https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal

I agree that it’s best to start with NSDecimal, and that approach 2 would offer the most flexibility.

I have a few other thoughts regarding the number behaviors.

NSDecimal’s functions accept rounding mode parameters and return NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior parameter and throws NSExceptions. I’m not really sure what the reason for this discrepancy is and should a new Swift NSDecimal use NSDecimalNumberBehavior, but maintain backwards compatibility with default behaviors and defined rounding mode?

Our primary goal is API compatibility across platforms. It would be really unfortunate if a client of Foundation had to #ifdef their code to account for a platform difference.

That’s not to say we can’t improve things (as we do with every release), but compatibility requirements are a fact of life for a low level library like ours. Our clients appreciate it. =)

Also, should a Swift NSDecimal continues with raising NSException, or adopt Swift style error handling? I don’t think we would want to introduce try/throw/catch semantics into the publicly exposed methods - but we could have an internal API layer which does. Backwards compatible functions would then have to convert between Swift ErrorType and NSException or NSCalculationError.

Anywhere that Darwin Foundation raises an NSException, we are replacing with fatalError, precondition, or similar. The root cause of either is the same (a programmer error). The try/catch/throws mechanism is for errors that we may want to present to a user at some point.

Hope this helps,
- Tony

Cheers,
Dan

p.s. in the linked project, I made a DecimalNumberType protocol generic over the Behavior, which I’m not entire sure was a good decision or not.

On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Tony Parker) #7

Thanks for the clarification Tony - and for reminding me of the primary goal r.e. API compatibility. :slight_smile:

This may be better suited to swift-evolution or users list, but regarding fatalError do you have any techniques for testing this behavior? I was thinking about an internal try/throw/ layer (which would then be caught and trampolined to fatalError for the public APIs) so that it would be possible to write unit tests for the edge cases where there is a calculation error.

Cheers,
Dan

It’s a good question regarding the testability of fatalError paths. I think it would be really unfortunate if we had to write our own trampolines every place that we wanted to use it, but I’m not sure how else to verify the behavior if we don’t want to allow every test case to crash. Let’s raise the issue on the more general swift-users list and see if anyone has any ideas.

- Tony

···

On Dec 11, 2015, at 1:02 PM, Dan Thorpe <dan@blindingskies.com> wrote:

On 11 Dec 2015, at 19:00, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:

Hi Dan, Florian,

I agree with Philippe that NSDecimal is a particularly troublesome area in terms of how poorly the API is imported into Swift.

Since NSDecimal is already a value type, it may be possible to do something better here ourselves without worrying about the bridging problem. It would be an API change, however, so we should follow the swift-evolution process.

NSDecimalNumber would be more complicated, since it’s a class (and furthermore, a subclass of NSNumber).

On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

I’d be really interested in working on a Swift decimal number type. I’ve done some work on this for a Money type here: https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal

I agree that it’s best to start with NSDecimal, and that approach 2 would offer the most flexibility.

I have a few other thoughts regarding the number behaviors.

NSDecimal’s functions accept rounding mode parameters and return NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior parameter and throws NSExceptions. I’m not really sure what the reason for this discrepancy is and should a new Swift NSDecimal use NSDecimalNumberBehavior, but maintain backwards compatibility with default behaviors and defined rounding mode?

Our primary goal is API compatibility across platforms. It would be really unfortunate if a client of Foundation had to #ifdef their code to account for a platform difference.

That’s not to say we can’t improve things (as we do with every release), but compatibility requirements are a fact of life for a low level library like ours. Our clients appreciate it. =)

Also, should a Swift NSDecimal continues with raising NSException, or adopt Swift style error handling? I don’t think we would want to introduce try/throw/catch semantics into the publicly exposed methods - but we could have an internal API layer which does. Backwards compatible functions would then have to convert between Swift ErrorType and NSException or NSCalculationError.

Anywhere that Darwin Foundation raises an NSException, we are replacing with fatalError, precondition, or similar. The root cause of either is the same (a programmer error). The try/catch/throws mechanism is for errors that we may want to present to a user at some point.

Hope this helps,
- Tony

Cheers,
Dan

p.s. in the linked project, I made a DecimalNumberType protocol generic over the Behavior, which I’m not entire sure was a good decision or not.

On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi all,

Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.

I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
What do you think?

Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?

—Florian

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Brent Royal-Gordon) #8

This may be better suited to swift-evolution or users list, but regarding fatalError do you have any techniques for testing this behavior?

I believe the Swift compiler’s tests run code it expects to trap in a separate process and verify that the other process trapped. We may want to think about extending XCTest in some way to offer this behavior.

···

--
Brent Royal-Gordon
Architechies