Bug 25181 - Ambiguity when wrapping a nested Type and a parameterless method getType
Summary: Ambiguity when wrapping a nested Type and a parameterless method getType
Alias: None
Product: Android
Classification: Xamarin
Component: Bindings ()
Version: 5.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Atsushi Eno
Depends on:
Reported: 2014-12-09 10:02 UTC by Dimitar Dobrev
Modified: 2014-12-09 14:21 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Dimitar Dobrev 2014-12-09 10:02:49 UTC
getType is mapped to a property named Type which creates ambiguity because of the nested Type, and prevents compilation.
In other words (Java):

public class Parent
    public class Type { }

    public int getType() { return 0; }
Comment 1 Dimitar Dobrev 2014-12-09 10:19:09 UTC
That should've been fixed by renaming:

<attr path="/api/package[@name='com.radiumone.android.volley']/class[@name='Request']/method[@name='getMethod' and count(parameter)=0]" name="managedName">GetMethod</attr>

but it's unfortunately completely ignored.
Comment 2 Dimitar Dobrev 2014-12-09 10:21:26 UTC
My second comment seems to concern an unrelated issue: any other name works which means it ignored "GetMethod" because it's an upper-cased version of the original name.
Comment 3 Dimitar Dobrev 2014-12-09 10:24:16 UTC
Also, when I rename it, regardless of the new name, it's no longer mapped to a property.
Comment 4 Atsushi Eno 2014-12-09 11:24:26 UTC
The bug report text itself and comment #1 to #3 doesn't match.

For the bug report itself: as you guessed you have to rename either the nested class or the method (or <remove-node>). That is not automatically taken care (binding generator is not an AI and won't give any appropriate renaming).

For the rest: Please explain what you are actually writing about.
Comment 5 Dimitar Dobrev 2014-12-09 11:44:02 UTC
About the current issue: it actually can be taken care of automatically. The binding generator could get the name of the property to generate (getType() -> Type) and then check if the new name causes conflicts. If it does, the generator could, for example, leave the original name for the property - GetType.

About the rest, the are unrelated, it's just that I discovered them while digging on this issue. I've filed them at https://bugzilla.xamarin.com/show_bug.cgi?id=25191 and https://bugzilla.xamarin.com/show_bug.cgi?id=25192.
Comment 6 Atsushi Eno 2014-12-09 14:21:34 UTC
Naming getType() method as GetType property doesn't make sense for most of developers. We'd leave this kind of naming conflict as corner case that binding developers should give meaningful name (we can make changes to generator to give random name or name that doesn't make sense, but that just annoys good developers and they will rename things by themselves).

Closing the bug as the rest of the issues are filed in different bugs (thanks!).