Use named parameters for Obj-C method name translation

[stuartmorgan]

The current Obj-C name generation makes clunky methods that don't feel like Dart or like Obj-C. I think it would be much better if it used heuristics like Swift/Obj-C interop, and signature segments were converted to named parameters instead.

E.g., NSNotificationCenter has

• addObserverForName:object:queue:usingBlock:, which
• ffigen renders as addObserverForName_object_queue_usingBlock_(NSString? name, ObjCObjectBase? obj, NSOperationQueue? queue, ObjCBlock<ffi.Void Function(NSNotification)> block), while
• Swift renders as addObserver(forName name: NSNotification.Name, object obj: Any?, queue: OperationQueue?, using block: @escaping @Sendable (Notification) -> Void )

I don't see why Dart couldn't make it addObserver({NSString name, ObjCObjectBase? object, NSOperationQueue? queue, ObjCBlock<ffi.Void Function(NSNotification)> block, or any other number of slight variations using heuristics of Obj-C naming conventions (like handling "with" and "from", if param names aren't always good enough).

This would give results more like Obj-C, more like idiomatic Dart, more like Swift, and more readable all around. They would be slightly less deterministically discoverable, but I would gladly trade that slight inconvenience for better readability and more idiomatic code. Especially since realistically I think we can expect most people to do what I'm doing, which is using IDE autocomplete rather than copy/pasting Obj-C signatures and manually translating them.

[liamappelbe]

There are a lot of ObjC methods that differ only by their param names. Eg in NSString:

- compare:options:
- compare:options:range:
- compare:options:range:locale:

The compare base names would clash, so we'd have to fall back to disambiguating by adding numbers. These would become:

NSComparisonResult compare(NSString string, {required NSStringCompareOptions options})
NSComparisonResult compare1(NSString string, {required NSStringCompareOptions options, required NSRange range})
NSComparisonResult compare2(NSString string, {required NSStringCompareOptions options, required NSRange range, required NSObject locale})
//                        ^- Deduped.

Even so, this might still be more user friendly. WDYT?

[stuartmorgan]

I forgot we can't overload in Dart. Hmm.

I expect code will be much more readable with the arbitrary de-duping, but the numbers are kind of weird.

For writing code, selecting the right variant from auto-complete will likely be harder. But accidentally passing params in the wrong order if they have the same type would be much harder, which is good.

And of course, a whole lot of methods won't have collisions. So I'm leaning toward thinking that it's probably a net win to use named parameters. Plus, we already have all the same de-duping problems for a Swift generator, right?