[Gtk-sharp-list] LibGlade

[Rachel Hestilow]

--=-ecrnCnU/3TNkrTPUvCnh
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2002-08-17 at 08:41, Paolo Molaro wrote:
> My issue is with:
> 	public class SList=20
> 	[...]
> 	public SList (IntPtr raw)
>=20
> If the type is made internal and exposed only as an IList reference
> I would have no problems.
> >=20
> That is only one of the issues. Look at this:
>=20
> 	public Object (IntPtr raw) (in glib/Object.cs)
>=20
> What happens if I pass an arbitrary value in there?
> I'm just raising the issue: do we want to be able to make untrusted code
> that uses Gtk safely? I think it's a worthwhile target.
> I don't have a solution, I didn't look at the binding design, but I
> think we should take it into account (and the above entry point makes
> it impossible to run safely untrusted code that uses Gtk#).

Internal types cannot be used cross-assembly, right? Currently, we have
a gdk-sharp, a gtk-sharp, a gnome-sharp, etc. Would you have us combine
all these into a single assembly? That doesn't seem appealing to me.

>=20
> Exactly. The binding is made to match the BCL rules (i.e. the C#
> paradigms), instead of following the Gtk API and exposing a
> BCL-conforming interface based on that.
>=20
> From a purely hypothetical point of view: I'm porting jpython to run on
> the mono CLR and I want to be able to run existing python gtk programs.
> Of course it would be very silly to write a new binding to libgtk that
> follows the (established) python way of doing the binding (usually a
> thin wrapper on the C API).
> With the current gtk# binding, the call chain for the python code:
>=20
> 	win.show_all ()
>=20
> will look like:
>=20
> 	win.show_all ()
> 	-> win.ShowAll ();
> 	   -> gtk_widget_show_all (IntPtr raw);
>=20
> Now, there are three issues with that:
> 1) an extra method call (minor, I know, but why impose it?)
> 2) mapping name issue: the python binding needs to map its
> method names based on the C API to the almost arbitrary BCL-compatible
> name (when it would be enough to just s/gtk_widget_//)
> 3) it would not be enough to make gtk_widget_show_all() public, because
> of the IntPtr type that is exposed (again, I think exposing methods that
> take IntPtr is dangerous and I would limit it also in the internals of
> the binding).
>=20
> So, my suggestion is to have the binding expose a thin wrapper over the
> C API and have the C# side of it provide the BCL-conforming method
> names, permitting other languages to reuse their existing mapping of the
> Gtk+ API without adding an extra layer that maps to the BCL-accepted name=
s
> (the imposed layer is a slight overhead at runtime, but a big wall to cli=
mb to
> have an existing binding work within the CLR).
>=20

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.

2) Almost arbitrary? It is a simple algorithm built into the code
generator system. _foo_bar maps into FooBar. The reverse mapping is a
simple one-line perl regex:
   s/([A-Z])/_\l$1/g;
What is so difficult about that?

3) Again, as the bindings near completion, the places in the public API
where IntPtr is exposed for non-binding usage will approach zero.
Exposing the DllImports would be of little to no help to you anyway,
there is a lot more to the bindings than that.

-- Rachel


--=-ecrnCnU/3TNkrTPUvCnh
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9XpK8apOJdUj74F4RApzjAJ9Cfwf/AttZA9hs8z5yzTMiZ8q59wCeNqEl
FXtzPBsNtLt9YQYf6/lqBwg=
=zft1
-----END PGP SIGNATURE-----

--=-ecrnCnU/3TNkrTPUvCnh--