Re: [swift-corelibs-dev] Asynchronous Operations

[Ian Partridge via swift-corelibs-dev]

Thank you everyone for your comments.

Adding willChangeValue(forKey:) and didChangeValue(forKey:) to
Operation does solve the problem for me.  The Swift 3 code I'm porting
from macOS to Linux works correctly when I patch Foundation as Brent
suggests.

I've opened a PR against swift-corelibs-foundation and would welcome
feedback on this.  Thank you.

https://github.com/apple/swift-corelibs-foundation/pull/836

P.S. The code I'm porting is roughly analogous to
https://gist.github.com/ianpartridge/e3b8496cb114005a93f5c86ff76af630
although it uses URLSession instead of an async dispatch queue.

On 23 January 2017 at 17:32, Tony Parker  wrote:
> Hm, that’s probably the least bad option we have at the moment.
>
> I don’t want to introduce “new” API, as it is unlikely we will be able to 
> remove it when whatever permanent solution comes up.
>
> - Tony
>
>> On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev 
>>  wrote:
>>
>>> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev 
>>>  wrote:
>>>
>>> Is there any way that we could support asynchronous operations in 
>>> swift-corelibs-foundation, in the absence of KVO?
>>
>> Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` 
>> methods just to `Operation` which only handle an `isFinished` key? 
>> Presumably they'd just look like:
>>
>>   public func willChangeValue(forKey key: String) {
>>   // do nothing
>>   }
>>   public func didChangeValue(forKey key: String) {
>>   if key == "isFinished" && isFinished {
>>   finish()
>>   }
>>   }
>>
>> I believe that would make existing code just work without needing to do 
>> anything special.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>



-- 
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Asynchronous Operations

[Tony Parker via swift-corelibs-dev]

Hm, that’s probably the least bad option we have at the moment.

I don’t want to introduce “new” API, as it is unlikely we will be able to 
remove it when whatever permanent solution comes up.

- Tony

> On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev 
>  wrote:
> 
>> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev 
>>  wrote:
>> 
>> Is there any way that we could support asynchronous operations in 
>> swift-corelibs-foundation, in the absence of KVO?
> 
> Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods 
> just to `Operation` which only handle an `isFinished` key? Presumably they'd 
> just look like:
> 
>   public func willChangeValue(forKey key: String) {
>   // do nothing
>   }
>   public func didChangeValue(forKey key: String) {
>   if key == "isFinished" && isFinished {
>   finish()
>   }
>   }
> 
> I believe that would make existing code just work without needing to do 
> anything special.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-corelibs-dev] Asynchronous Operations

[Brent Royal-Gordon via swift-corelibs-dev]

> On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> Is there any way that we could support asynchronous operations in 
> swift-corelibs-foundation, in the absence of KVO?

Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods 
just to `Operation` which only handle an `isFinished` key? Presumably they'd 
just look like:

public func willChangeValue(forKey key: String) {
// do nothing
}
public func didChangeValue(forKey key: String) {
if key == "isFinished" && isFinished {
finish()
}
}

I believe that would make existing code just work without needing to do 
anything special.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-corelibs-dev] Asynchronous Operations

[Philippe Hausler via swift-corelibs-dev]

> On Jan 20, 2017, at 7: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?

So perhaps you misunderstood my comment? What are you meaning by asynchronous 
operation? Technically all operations running in a queue are “asynchronous” on 
Darwin or on Linux. 

My commentary was about the cases where main finishes execution and the 
operation is not finished.

The subclassers of Operation would need to somehow notify the super-class that 
the operation is finished. And we would need to have a mechanism to understand 
if the subclasser is overriding main or start (or both?!)

> 
> Might it be acceptable to add extra temporary public API to enable this?

There is never a thing as temporary API - it haunts us for ever ;)

I think it would be better to advocate a sound design pattern that would 
facilitate proper implementations on all platforms instead… Perhaps like; how 
does one properly use run loops in the context of Operation or dispatch. Often 
that is a suitable way to make things that act asynchronously without consuming 
another thread/queue.

> 
> Many thanks,
> 
> -- 
> Ian Partridge
> 
> ___
> 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

Re: [swift-corelibs-dev] Asynchronous Operations

[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
> 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] Asynchronous Operations

[Ian Partridge via swift-corelibs-dev]

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?

Many thanks,

-- 
Ian Partridge
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev