Re: [swift-corelibs-dev] NSDecimal & NSDecimalNumber

2015-12-11 Thread Matthew Johnson via swift-corelibs-dev 
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 
>  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 
>>  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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Asynchronous Operations

2017-01-20 Thread Matthew Johnson via swift-corelibs-dev 

> On Jan 20, 2017, at 9:55 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> On Darwin, asynchronous usage of Operation is supported via KVO notifications.
> 
> Because KVO is only available on Darwin platforms, swift-corelibs-foundation 
> currently does not support asychronous Operations, and there is a comment to 
> that effect:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd75/Foundation/NSOperation.swift#L50
>  
> 
> 
> My understanding is that it's unlikely KVO will arrive on Linux any time 
> soon, so this leaves us with a problem in Operation.  Asynchronous usage of 
> Operation is an important feature.
> 
> Is there any way that we could support asynchronous operations in 
> swift-corelibs-foundation, in the absence of KVO?
> 
> Might it be acceptable to add extra temporary public API to enable this?

+ 1.  IMO eliminating the dependence of an API like this on KVO would be a good 
thing regardless of whether KVO is present or not.

> 
> Many thanks,
> 
> -- 
> Ian Partridge
> 
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev