[Gtk-sharp-list] Why does gtk sharp still use mcs (.NET 1.1)

[Mike Kestner]

On Thu, 2008-02-07 at 23:17 +0100, Anders Rune Jensen wrote:
> On Feb 7, 2008 8:39 PM, Christian Hergert <christian.hergert at gmail.com> wrote:
> > Remember there are a lot of people that don't target the 2.0 runtime
> > yet. Going to generics would totally alienate them.
> 
> And keeping with 1.1 only will falsely make people think that mono is
> a big memory hog when it fact it's merely a problem with the gtk
> bindings.

Gtk# has to continue to work on 1.0 for as long as mono continues to
support it as a mainstream option, which it still clearly does.

If I understand the scenario correctly, in order for us to continue that
support, while also supporting a performance enhanced version for 2.0
users, we would have to install two separate versions of the Gtk#
assemblies which reference the 1.1 and 2.0 corlibs and somehow come up
with a mechanism to allow compiling against each version.  

My guess is that users would want that selection to happen automatically
based on the choice between gmcs and mcs.  I can't even think of a way
to do that without hacking mcs/gmcs, which I suspect would be met with
resistance.

The installed and downloadable footprint of Gtk# would essentially
double.  The Gtk# codebase would increase in complexity because of
conditional compilation to activate the use of generic and non-generic
code paths.

Those are among the reasons Gtk# will most likely not see a 2.0
dependency any time soon.  

Now, as to your original observation of boxing issues with ArrayList, as
Miguel pointed out to me on IRC, that can easily be worked around by
using a uint[] instead and manually growing/shrinking it.  I would be
more likely to accept a patch like that, with corresponding profiling
results, than a new dependency on 2.0.

Mike