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
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
