Community
Participate
Working Groups
I would like to be able to generate a Java varargs declaration when the last parameter in an operation is declared with an upper bound of -1. At present, it is declared as an EList<T> instead and there's no way for me to override it.
We can't just change the meaning for existing constructs... It definitely would be nice to be able to express varargs though (which are really much like an array type, not a list).
Perhaps you could add a condition to the genmodel that would allow the parameter to be generated differently? The default behavior would of course remain the same as today.
It would make sense to include an annotation on either the operation or the parameter (only the last parameter can be a vararg) that would generate X... instead of X[]. A vararg is after all purely syntactic sugar for implicit array literals so it seems best to stick with an EDataType representing an array rather than contorting the meaning for unbounded...
The syntax also affects the caller so I think a request to support varargs makes a lot of sense. The method declarations: void foo(String[] args) { } and: void foo(String...args) { } will impose different requirements on how a call must be written. If you write: foo("", ""); to call the first form, you'll get the error "The method foo(String[]) in the type SampleClass is not applicable for the arguments (String, String). Supporting arrays would of course be a good first step but forcing all calls to be in the form: foo(new String[] { "", "" }) just because it's more pure would be bad IMO. Why not support both forms?
What I was suggesting was to support an annotation that would make the final parameter, if it's an EDataType that's an array (i.e., if the instance type name ends with []), be generated as ... instead of []. This way, reflectively, i.e., for EObject.eInvoke, there's really nothing special needed.
