[swift-evolution] [Review] SE-0160: Limiting @objc inference

[Jonathan Hull]

> On Mar 23, 2017, at 1:46 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md]
>> 
>> I'm definitely in favor of this. Apart from the various motivations discussed in the proposal, this also allows some changes that could improve incremental builds: the generated header ("MyApp-Swift.h") wouldn't need to be regenerated nearly as often with fewer methods exposed to Objective-C. (There's some nuance here that I don't need to go into right now, and there are alternate solutions to that problem, but it's nice that the common case will just put fewer declarations into the header and therefore it would change less often.)
>> 
>> The migration aspect is a little scary. #selector's Objective-C equivalent is @selector, which is easy to search for, but #keyPath maps to plain old strings.
> 
> Are these strings usually literal strings that are passed in to some set of mostly-known selector names, or do people pass them around or even construct them dynamically?

I have cases where I read the strings in from a plist or json, and then use them to bind the model with the UI (which may have been auto generated).  For example, I have a file which defines a UI which should be dynamically generated, and then binds the generated interface to a facade which talks to a database (performing any conversions necessary to make the connections work).  That way, I can add new types of things simply by adding a plist to my app (which is much easier and less error prone than hand coding each sub-UI)

I have been experimenting with doing this in a swift-ier way lately, with some success, but it is still much more complex and finicky than the ObjC way.

Thanks,
Jon