Bugzilla – Full Text Bug Listing
| Summary: | [Xbase / Common Types] Allow multiple types type reference | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Sven Efftinge <sven.efftinge> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | knut.wannheden, sebastian.zarnekow |
| Version: | 2.0.0 | Flags: | sven.efftinge:
indigo+
|
| Target Milestone: | M7 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=340611 | ||
| Whiteboard: | |||
Maybe we should have something like an explicit AnyTypeReference as well instead of using void / java.lang.Void to express the return type of a method foo() return null The AnyTypeReference could be serialized to java.lang.Object if no further constraints are present while dispatch foo(A a) return null dispatch foo(B b) return '' could yield java.lang.String for foo(AorB instance) since there the common super type for the AnyTypeReference and type X should be type X. So far we use Void in the signature of dispatch methods to catch null references. I think effectively java.lang.Void is our AnyRef. Does overloading java.lang.Void cause any problems? (In reply to comment #2) > So far we use Void in the signature of dispatch methods to catch null > references. > I think effectively java.lang.Void is our AnyRef. Does overloading > java.lang.Void cause any problems? I've got the impression that the type inference code is harder to read, write and maintain due to the overloaded semantics of java.lang.Void. There is e.g. the compiler who should usually create java.lang.Object as infered return type when somebody returns null, except when the super method already defined java.lang.Void explicitly (like in MySwitch extends EPackageSwitch<Void>) so we somehow have to maintain additional information with any TypeReference to java.lang.Void whether its intentional or the AnyType. Well, at least that was my impression when I thought about the semantics that we introduced. I've filed a bugzilla for the AnyType issue : #341352 (In reply to comment #4) > I've filed a bugzilla for the AnyType issue : Bug 341352 Pushed to master. Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |
In Xbase there are a couple of situations when it would be helpful/necessary to have a TypeReference representing multiple types. One is in case of branched expressions where multiple common super types are possible, it would be good to pass that information until it is decided which one to use. Example: val x = if (predicate) 'foo' else new StringBuilder('foo') x.compareTo('bar') (i.e. String and StringBuilder both implement Comparable and CharSequence) Also in for expression we want to allow arrays or iterables. In order to use TypeProvider's expectedType we need to be able to return a type reference representing both. There are a couple of existing type inference bugs depending on this.