Bug 681 - gtk-gui/*.cs Generates incorrect properties (private readonly) which fail to compile
Summary: gtk-gui/*.cs Generates incorrect properties (private readonly) which fail to ...
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: GTK# Designer ()
Version: Trunk
Hardware: PC Linux
: Normal critical
Target Milestone: 2.8
Assignee: Lluis Sanchez
Depends on:
Reported: 2011-09-09 03:13 UTC by cmdematos@gmail.com
Modified: 2012-01-06 10:09 UTC (History)
3 users (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 cmdematos@gmail.com 2011-09-09 03:13:49 UTC
When compiling MD's Main.sln using MD generates all Stetic *.cs files in gtk-gui incorrectly.

Class fields (private) are further being marked readonly which is incorrect (private should be enough) and is causing compile errors.

Once generated incorrectly, user has now corrupted code and cannot recompile to fix.
Comment 1 Lluis Sanchez 2011-09-27 10:53:42 UTC
I can't reproduce. Which Mono version are you using?
Comment 2 cmdematos@gmail.com 2011-09-27 11:08:37 UTC
Lluis, this occurs in Linux with the latest branch. Steps to reproduce:

1. Get latest branch or everything
2. Compile libgdisharp, llvm, mono, monodevelop (with debugger and web)
3. launch monodevelop
4. Open Main.sln using monodevelop you compiled (but fails just the same in MD2.4 & MD2.6)
5. Compile

During compilation the gtk partial source files are generated. Some (most) are generated with private readonly properties. These properties are set in a private method that is called by the forms constructor.

There are several issues:

1. The compiler is throwing a compilation error but fails to see that the readonly fields are in fact being set by the constructor (via the method that sets them which is only called only from the constructor).

2. The use of private readonly is redundant for a field that is set by code other than the field declaration.

I fixed this temporarily by calling string.Replace(" readonly ", " ");
on the text generated by the gtk service before it is formatted with the IDE/users C# format options. The actual code that generates the C# from the stetic gtk designer file is DI'ed somehow, and I have not discovered it yet.

2 other observations:

There is ZERO documentation in the code (for the most part) and ZERO documentation for the classes (what is this class responsible for?) and ZERO documentation for the Assemblies (why does this assembly exist?). By comparison with Java FOSS projects, I am very disappointed.
Comment 3 Lluis Sanchez 2011-09-28 12:40:27 UTC
This was a regression in Mono, which was inserting the readonly keyword when it shouldn't. It's now fixed in Mono master.

I'm sorry you are very disappointed with my work. I'll do my best to do it better next time.
Comment 4 cmdematos@gmail.com 2011-09-28 20:04:55 UTC
Lluis, by no means am I disappointed with your work, or the work of any other contributor the project. My disappointment is a general statement regarding the state of the project documentation on the whole. I think this is historic and can be easily rectified over time if we raise the standards and encourage adherence.

The following will greatly assist people in contributing to the project by lowering the learning barrier-to-entry.

For each assembly there should be a document that describes that assemblies reason for being.

For each class there should be a clear responsibility statement.

For each method, no matter how well named, the methods responsibility should be stated. 

For each IOC/DI abstraction / factory / interface there should be a comment on where the configuration / strategy pattern comes from, or there should be some centralized documentation for this. An example of this is the extensive use of plugins, which also are used to generate the GTK code. Without compiling and executing the code it is quite hard to follow what code is actually generating the source code that contained that readonly.

My point is this - we should take a leaf from the Java FOSS folks and greatly increase our in-code documentation, because doing so makes it easier to receive contributions. I could easily have issued you a fix/patch for this issue instead of opening a bug report, but it took me for-ever to track the bug to the code generation point. I had spent too much time on it so the time left only allowed me to inject a work-around into the code instead of producing a proper fix. 

Both the paid and contributing developers should be rightly proud of their work here. I just ask that we lower the barrier to entry for further contributions, especially important as the code base matures.