Created attachment 385208 [details] Patch

Comment on attachment 385208 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=385208&action=review > Source/WebKit/ChangeLog:4 > + Allow _WKRemoteObjectRegistry to pass a nil reply block > + https://bugs.webkit.org/show_bug.cgi?id=205036 Why are you making this change? What advantage is there to supporting nil reply blocks?

Without this change, I either have to have two selectors (one with a completion block, one without), or I have to pass a boolean parameter indicating whether to call the completion block (which results in a wasted IPC). See rdar://problem/57081053 for why I want an optional reply.

(In reply to Alex Christensen from comment #3) > Without this change, I either have to have two selectors (one with a > completion block, one without), or I have to pass a boolean parameter > indicating whether to call the completion block (which results in a wasted > IPC). See rdar://problem/57081053 for why I want an optional reply. I think having a two selectors sounds better. What is the downside to that? Or, alternatively, what would the downside of passing an empty block be?

(In reply to Sam Weinig from comment #4) > (In reply to Alex Christensen from comment #3) > > Without this change, I either have to have two selectors (one with a > > completion block, one without), or I have to pass a boolean parameter > > indicating whether to call the completion block (which results in a wasted > > IPC). See rdar://problem/57081053 for why I want an optional reply. > > I think having a two selectors sounds better. What is the downside to that? > Or, alternatively, what would the downside of passing an empty block be? Oh, actually, I see the downside of the empty block case, so now I am just curious what the downside of two selectors is?

I think it unnecessarily clutters up the interface. Blocks can be nil everywhere else in the language, why not at this interface? I think this makes remote objects more useable

(In reply to Alex Christensen from comment #6) > I think it unnecessarily clutters up the interface. Blocks can be nil > everywhere else in the language, why not at this interface? I think this > makes remote objects more useable I don't think that is generally true that nil can be passed everywhere else, but in this case, this SPI is meant to parallel NSXPCConnection, which, does not allow nil blocks, and keeping that consistency seems like a good thing.

Whatever. I'm just adding double selectors for now.