Comment 1 Matt Heitz 2011-08-26 10:09:50 EDT

I changed the summary since the original problem description is really one case out of many.  The generator needs to understand that multiple EGL types can be represented by the same class in the Java.  It needs to be dealt with using the properties for extensibility.

In addition to dates and timestamps both being Calendars, all arrays are EglLists, strings and the other text types are Strings, etc.

In EDT the IR of a function can tell us if it's overloaded.

The problem might be solved using type constraints and/or additional arguments to the function (for example pass in the length or pattern).

In RBD our solution for overloaded function Foo is to generate a private method for each version of the function.  The method's name will be "Foo" plus a suffix based on the type.  We also make a public method named simply "Foo", which is passed an Object, determines its type, then calls the proper private method.  Within the piece of code being generated, the private methods are called directly.  But when the function is called from some other part, the public method is invoked.  (This is important because it preserves the public API of the part with the overloaded function.  Suppose a library had one function called Foo, which was generated as a method named "Foo".  Clients of the library contain calls of Foo.  Then a new version of Foo is added to the library.  The clients of the library must still work, and they must not require regeneration.)

Comment 2 Jeff Douglas 2011-09-17 22:15:35 EDT

Just an update. I understand the problem, however just an FYI about the calendar object. When creating a date, the runtime code does not set the time fields of the calendar object and this can be tested to determine if the calendar object is a date or not. 

However, that doesn't change the idea about the need for modifying the function name.

Comment 3 Matt Heitz 2011-09-19 08:09:45 EDT

Is there a difference between a Calendar for a date and a Calendar for a timestamp("yyyyMMdd")?

Comment 4 Matt Heitz 2011-09-20 20:44:57 EDT

*** Bug 358312 has been marked as a duplicate of this bug. ***

Comment 5 Matt Heitz 2011-09-21 11:19:23 EDT

*** Bug 358312 has been marked as a duplicate of this bug. ***

Comment 6 Kathy Carroll 2011-10-12 09:29:44 EDT

Created attachment 205032 [details]
Additional Variations

Attached related eunit test variations.  Run RunAllTests_pgms

Comment 7 Brian Svihovec 2011-12-16 15:01:33 EST

This may be covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=359315

Comment 8 Jeff Douglas 2012-06-25 14:55:05 EDT

Update:

I have done some more investigation on this and I do not see how any solution can be implemented either with Matt's suggestion (common function redirector) or Scott's suggestion (preprocessing the IRs and changing the function name to the altered one). 

Take this EDT example:

	function myFunc(a date in)
	end
	function myFunc(a timestamp in)
	end

	function myFunc(a date inout)
	end
	function myFunc(a timestamp inout)
	end

The generated code for these functions is:

	public void myFunc(Calendar a) {
	}
	public void myFunc(Calendar a) {
	}

	public void myFunc(AnyBoxedObject<Calendar> a) {
	}
	public void myFunc(AnyBoxedObject<Calendar> a) {
	}

If we have a redirector method, there is nothing that can be checked at runtime to determine which method the user really means to call (Calendar object is the same as Calendar object). We'd have to pass along some type of argument information (such as a string defining what is being passed) to determine the desired method, but doing so would make the outside world not able to naturally call the common redirector method because additional parms would have to be used.

If we restricted this overloading to only be allowed by EDT functions and not the outside world, then it is possible to solve. I believe that restriction is not desirable by the architects of this language.