polytronicgr / sharpkit

Automatically exported from code.google.com/p/sharpkit
0 stars 0 forks source link

Method overload name resolution collision #328

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a class with the following methods:

    public static void M<T>(IDictionary<string, int> arg1, string arg2)
    {
    }

    public static void M<T>(IDictionary<T, int> arg1, int arg2)
    {
    }

    public static void M<T>(IDictionary<T, string> arg1, int arg2)
    {
    }

2. Compile it using SharpKit
3. View the output:

    M$1$$IDictionary$2$String$Int32$$String: function (T, arg1, arg2)
    {
    },
    M$1$$IDictionary$2$$Int32: function (T, arg1, arg2)
    {
    }

What is the expected output? What do you see instead?

I expected to see *three* methods output since I provided three methods.  The 
reason it did not produce three is because the method name generation algorithm 
appears to treat type arguments to a method parameter's type as special if the 
type argument is actually a method's type parameter.

Consider the following method signature:

public static void M<T>(IDictionary<string, int> arg1, string arg2)

Now examine its generated name:

M$1$$IDictionary$2$String$Int32$$String

You'll notice that the syntax is: 
<METHOD_NAME>$<TYPE_PARAM_COUNT>$$<PARAM1_TYPENAME>$<PARAM1_TYPE_PARAM_COUNT>$<P
ARAM1_TYPE_PARAM1_TYPENAME>$<PARAM1_TYPE_PARAM2_TYPENAME>$$<PARAM2_TYPENAME>

Now consider the following method signatures:

public static void M<T>(IDictionary<T, int> arg1, int arg2)
public static void M<T>(IDictionary<T, string> arg1, int arg2)

And their generated name:

M$1$$IDictionary$2$$Int32

Here the syntax is:
<METHOD_NAME>$<TYPE_PARAM_COUNT>$$<PARAM1_TYPENAME>$<PARAM1_TYPE_PARAM_COUNT>$$<
PARAM2_TYPENAME>

You'll notice that because these methods have a parameter (arg1) whose type is 
a generic type, and one of the type *arguments* to that generic type is T, the 
type parameter declared in the method, it generates the name in a completely 
different way.

My suggestion would be to *always* generate the name like the first example, 
type parameters should be treated as ordinary types and the name should be the 
long version so that you avoid collisions.

What version of the product are you using? On what operating system?

SharpKit 5 v5.2.1

Please provide any additional information below.

Original issue reported on code.google.com by kirk.w...@gmail.com on 26 Nov 2013 at 11:03

GoogleCodeExporter commented 8 years ago
I think that Sebastian has fixed some issues related to method overload naming, 
so this might be already fixed in later versions. Sebastian can you comment on 
this?

Original comment by DanelK...@gmail.com on 5 Dec 2013 at 10:25