17 Aug 2002 13:15:24 -0500
On Sat, 2002-08-17 at 08:41, Paolo Molaro wrote:
> My issue is with:
> public class SList=20
> public SList (IntPtr raw)
> If the type is made internal and exposed only as an IList reference
> I would have no problems.
> That is only one of the issues. Look at this:
> public Object (IntPtr raw) (in glib/Object.cs)
> 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.
> 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.
> 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:
> win.show_all ()
> will look like:
> win.show_all ()
> -> win.ShowAll ();
> -> gtk_widget_show_all (IntPtr raw);
> 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).
> 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=
> (the imposed layer is a slight overhead at runtime, but a big wall to cli=
> 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.
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:
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.
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
-----END PGP SIGNATURE-----