Community
Participate
Working Groups
In case a null reference is passed as an argument to invoke, getDefaultClass(int) is called in order to allow to map null to a certain default type. That might be useful, but mapping any nulls to Object.class by default is wrong, since null is a member of any reference type. Instead the method should return null by default and the dispatcher should handle null as compatible to any reference type.
Should be dispatch null-params to method(Void v) ?
Sorry, typo: Should we dispatch null-params to method(Void v) ?
If we would assume Void.class for any nulls in Java, the client would always have to specify such a method signature. This is because Void has no super type (other than Object). We could of course mimic that Void is a subtype of everything, but that would complicate things and I'm not sure it is worth it.
Agreed. So by default you'd actually not call any method if null is passed to the dispatcher and more than one possibility exists?
By default the most specific signature is called (like it is with any other arguments) and in case there is no single most specific and error is raised. I'm not completely sure that being able to explicitly fetch null arguments by adding a signature for Void couldn't be useful. In Xtend I used that feature quite often. Maybe we should do it someday...
Changed the semantics, such that Void can be used to fetch null arguments.
Closing all bugs that were set to RESOLVED before Neon.0
