native
native copied to clipboard
dart-lang
Some ObjC method overrides map to invalid Dart overrides
NSNotificationCenter has a addObserver:selector:name:object: method, where the object param has type id (the super type of all objects, like Dart's Object), which makes sense. Meanwhile, NSDistributedNotificationCenter overrides that method but changes the type of the object param to an NSString*. This appears to be a bug in the API.
This is not a big deal for the ObjC compiler, which is generally much less strict than Dart. But when we generate the Dart wrapper API, having a method on NSDistributedNotificationCenter that overrides a method on NSNotificationCenter with more specific arg types is a compile error.
To fix this we'll need to adjust the types of any method args that conflict like this so that the subtype's method args are as general as the supertype's. We should also do the converse for the return type.
There's also a similar issue where an ordinary method is overridden by a getter.
This one is trickier because this method/getter difference is not allowed in either direction in Dart. The getter cannot be converted into an ordinary method because there may be a setter that it would conflict with. So we have to convert the ordinary method into a getter instead. This could cause further conflicts with other classes in the inheritance tree, so we'll have to keep converting every such method in the tree into a getter. Specfically, we walk up the tree until we hit a type that doesn't have this method, then convert this method to a getter for every subtype of that subtree.
I think the fix for the method/getter clash is going to be fiddly enough that it's probably time to bite the bullet and implement the transformer refactor: #1259
To fix this we'll need to adjust the types of any method args that conflict like this so that the subtype's method args are as general as the supertype's. We should also do the converse for the return type.
Drive by comment: I believe this will still work correctly when the bindings happen to be in different FFIgen generated bindings and the import feature is used. E.g. the base bindings don't need to know some extended bindings have type errors, because we'd adjust the types of the extended bindings instead of the base bindings. We should probably make sure this is covered by a test case.
There's also a similar issue where an ordinary method is overridden by a getter.
If this issue is going to cover this case, I would recommend retitling it; there's nothing invalid about this in Objective-C.
