Miguel de Icaza
19 Aug 2002 15:14:46 -0400
> > > names, permitting other languages to reuse their existing mapping of the
> > > Gtk+ API without adding an extra layer that maps to the BCL-accepted names
> > > (the imposed layer is a slight overhead at runtime, but a big wall to climb to
> > > have an existing binding work within the CLR).
> > >
> > 1) Why should the users of languages that follow the .NET naming
> > conventions be penalized for languages that don't? There are many naming
> > conventions out there. It is a language's responsiblity to map its
> > conventions to .NET conventions, and that includes naming conventions.
> There is no additional overhead for the BCL convention in my proposal
> (well, at most a -inlinable- function call to get a trustable API).
> Plus, you should also consider the overhead for the developers
> that know the C, python, perl API and have read the books and the
> tutorials on the familiar gtk API and that now have to learn a different
> API: developer mental cost is way higher than runtime cost.
The C, Python and Perl bindings are all different. Also put into the
mix the C++ binding for good measure. Knowing one of the bindings will
help you learn the others, but those bindings have been pretty focused
on improving Gtk programming with the particular idioms used in a
I think Gtk# should follow that path and provide the best possible
binding for the .NET Framework. If we get Gtk+ working nicely on
Windows and Aqua in the future (using native widgets for instance), then
we could use this as a nice cross platform API, which is nicely
integrated with .NET, and not with the old code base.