| Summary: | [Polymorphic Dispatcher] null values should be handled as compatible by default | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Sven Efftinge <sven.efftinge> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | sebastian.zarnekow |
| Version: | 2.0.0 | Flags: | sven.efftinge:
indigo+
|
| Target Milestone: | M3 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Sven Efftinge
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 Closing all bugs that were set to RESOLVED before Neon.0 |