This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?
This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?
It is following the naming methodology of a sentence like structure
"performed selector in background <selector> with <object>". It does read a
little strange but likely comes from a simple remapping of the existing
objective-c name for familiarly reasons.
It could be performInBackground(selector:,with:) ... "Perform in background
<selector> with <object>" but that also reads a little strange.
-Shawn
···
On Tue, Aug 16, 2016 at 8:40 AM Paul Hudson via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote:
Hello!
I just noticed that performSelectorInBackground(_:withObject:) has
been mapped to performSelector(inBackground:with:) in Swift 3. So:
This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?
This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?
Unfortunately per timing wise we are really late in the game to fix the names of things. It would require a full API review to push through a better name for it. (However I agree that perhaps we should rename them)
Also there were a pair of block variants added to RunLoop that falls into this family:
open func perform(inModes modes: [RunLoopMode], block: @escaping () -> Swift.Void)
open func perform(_ block: @escaping () -> Swift.Void)
···
On Aug 16, 2016, at 8:42 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Aug 15, 2016, at 3:53 PM, Paul Hudson via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
open func perform(inBackground aSelector: Selector, with anArgument: Any?)
That way it matches the completion family of the rest of performing. But if that is the case we should take a look at the onMainThread ones as well so they look like this perhaps:
open func perform(onMainThread aSelector: Selector, with arg: Any?, waitUntilDone wait: Bool, modes array: [String]?)
That way the call sites would look like this:
myObject.perform(inBackground: selector(doBackgroundStuff), with: nil)
myObject.perform(onMainThread: selector(doMainThreadStuff), with: nil)
myObject.perform(selector(doDelayedThings), with: nil, afterDelay: 0.7)
let result = myObject.perform(selector(doThingsNow), with: nil).takeUnretainedValue()
···
On Aug 16, 2016, at 8:46 AM, Shawn Erickson via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
It is following the naming methodology of a sentence like structure "performed selector in background <selector> with <object>". It does read a little strange but likely comes from a simple remapping of the existing objective-c name for familiarly reasons.
It could be performInBackground(selector:,with:) ... "Perform in background <selector> with <object>" but that also reads a little strange.
-Shawn
On Tue, Aug 16, 2016 at 8:40 AM Paul Hudson via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
Hello!
I just noticed that performSelectorInBackground(_:withObject:) has
been mapped to performSelector(inBackground:with:) in Swift 3. So:
This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?
Ah yeah didn't notice the others got named that way without the selector
after perform. Yeah it seems like it was simply mismapped. I suggest
filling a radar about ASAP (not in the standard library realm).
···
On Tue, Aug 16, 2016 at 8:52 AM Philippe Hausler <phausler@apple.com> wrote:
I would claim that perhaps it should be:
open func perform(inBackground aSelector: Selector, with anArgument: Any?)
That way it matches the completion family of the rest of performing. But
if that is the case we should take a look at the onMainThread ones as well
so they look like this perhaps:
open func perform(onMainThread aSelector: Selector, with arg: Any?,
waitUntilDone wait: Bool, modes array: [String]?)
That way the call sites would look like this:
myObject.perform(inBackground: selector(doBackgroundStuff), with: nil)
myObject.perform(onMainThread: selector(doMainThreadStuff), with: nil)
myObject.perform(selector(doDelayedThings), with: nil, afterDelay: 0.7)
let result = myObject.perform(selector(doThingsNow), with:
nil).takeUnretainedValue()
On Aug 16, 2016, at 8:46 AM, Shawn Erickson via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:
It is following the naming methodology of a sentence like structure
"performed selector in background <selector> with <object>". It does read a
little strange but likely comes from a simple remapping of the existing
objective-c name for familiarly reasons.
It could be performInBackground(selector:,with:) ... "Perform in
background <selector> with <object>" but that also reads a little strange.
-Shawn
On Tue, Aug 16, 2016 at 8:40 AM Paul Hudson via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:
Hello!
I just noticed that performSelectorInBackground(_:withObject:) has
been mapped to performSelector(inBackground:with:) in Swift 3. So:
This seems confusing to me – the "inBackground" label has little to do
with the selector that is attached to it. It's possible this has been
through careful API review and if so I apologize. On the other hand,
if it's an oversight is there time for it to be looked at again?