Recently, I've spent some time discovering type systems theory and got hook to strong statically-typed languages benefits. I just want a compiler to catch more errors thus giving me thrust and guarantees in the predictability of the product and its code.
I also like my IDE to have a lot of contextual data to help me through the implementation. Completion, early errors and defects detection are quite lifesavers.
Contrary to what one might naively expect from a compiled language, C/GObject lakes such insurances and proofs about the correctness of the generated binary.
GCC unawareness of anything but structs and functions makes it a bad helping hand when it comes to code with confidence.
In order to provide OO idioms to developers, GObject does most of its typing at runtime: types, signals and properties are all resolved and bound at the last minute.
Thereby a successfully compiled binary might fail at runtime for type related issues that a compiler could have spotted earlier. Typoing "opened" instead of "open" as signal or property name might have unexpected consequences at execution for example.
Test coverage should include reading stderr where Glib/GObject throws type warning. Not fun as it implies a edit-compile-run loop.
Lets illustrate the issue. In the following code the signal is always referred as an int within an enum or a string. Arbitrary values could be passed without the compiler to raise any flag. Also the arguments typing is enforced only at runtime through a complex marshaling system. Here again, mistakes might sneak in:
C/GObject (example taken from http://simonpena.com/blog/mswl/discovering-gobject-signals/ )
Some languages bindings with compiler's support of OO idioms exists (Vala, Gtkmm, C#, java-gnome., mono...). Their compilers checks the correctness of types/signals/properties definitions and accesses. Note bellow how both the signal and its handler parameter are typed thus bindings error will be caught at compilation:
Gtkmm
Vala
More than their conciseness, the aforementioned benefits of strongly typed bindings makes them really advisable to newcomers IMHO. The C API might be improved by enforcing the wrapping of signals and their handlers within class. This solution implies some verbosity and a more complex bindings generation that could hinder its desirability. Not my call!
dimanche 30 septembre 2012
Typesafe GObject through static bindings
Recently, I've spent some time discovering type systems theory and got hook to strong statically-typed languages benefits. I just want a compiler to catch more errors thus giving me thrust and guarantees in the predictability of the product and its code.
I also like my IDE to have a lot of contextual data to help me through the implementation. Completion, early errors and defects detection are quite lifesavers.
Contrary to what one might naively expect from a compiled language, C/GObject lakes such insurances and proofs about the correctness of the generated binary.
GCC unawareness of anything but structs and functions makes it a bad helping hand when it comes to code with confidence.
In order to provide OO idioms to developers, GObject does most of its typing at runtime: types, signals and properties are all resolved and bound at the last minute.
Thereby a successfully compiled binary might fail at runtime for type related issues that a compiler could have spotted earlier. Typoing "opened" instead of "open" as signal or property name might have unexpected consequences at execution for example.
Test coverage should include reading stderr where Glib/GObject throws type warning. Not fun as it implies a edit-compile-run loop.
Lets illustrate the issue. In the following code the signal is always referred as an int within an enum or a string. Arbitrary values could be passed without the compiler to raise any flag. Also the arguments typing is enforced only at runtime through a complex marshaling system. Here again, mistakes might sneak in:
C/GObject (example taken from http://simonpena.com/blog/mswl/discovering-gobject-signals/ )
Some languages bindings with compiler's support of OO idioms exists (Vala, Gtkmm, C#, java-gnome., mono...). Their compilers checks the correctness of types/signals/properties definitions and accesses. Note bellow how both the signal and its handler parameter are typed thus bindings error will be caught at compilation:
Gtkmm
Vala
More than their conciseness, the aforementioned benefits of strongly typed bindings makes them really advisable to newcomers IMHO. The C API might be improved by enforcing the wrapping of signals and their handlers within class. This solution implies some verbosity and a more complex bindings generation that could hinder its desirability. Not my call!
I also like my IDE to have a lot of contextual data to help me through the implementation. Completion, early errors and defects detection are quite lifesavers.
Contrary to what one might naively expect from a compiled language, C/GObject lakes such insurances and proofs about the correctness of the generated binary.
GCC unawareness of anything but structs and functions makes it a bad helping hand when it comes to code with confidence.
In order to provide OO idioms to developers, GObject does most of its typing at runtime: types, signals and properties are all resolved and bound at the last minute.
Thereby a successfully compiled binary might fail at runtime for type related issues that a compiler could have spotted earlier. Typoing "opened" instead of "open" as signal or property name might have unexpected consequences at execution for example.
Test coverage should include reading stderr where Glib/GObject throws type warning. Not fun as it implies a edit-compile-run loop.
Lets illustrate the issue. In the following code the signal is always referred as an int within an enum or a string. Arbitrary values could be passed without the compiler to raise any flag. Also the arguments typing is enforced only at runtime through a complex marshaling system. Here again, mistakes might sneak in:
C/GObject (example taken from http://simonpena.com/blog/mswl/discovering-gobject-signals/ )
Some languages bindings with compiler's support of OO idioms exists (Vala, Gtkmm, C#, java-gnome., mono...). Their compilers checks the correctness of types/signals/properties definitions and accesses. Note bellow how both the signal and its handler parameter are typed thus bindings error will be caught at compilation:
Gtkmm
Vala
More than their conciseness, the aforementioned benefits of strongly typed bindings makes them really advisable to newcomers IMHO. The C API might be improved by enforcing the wrapping of signals and their handlers within class. This solution implies some verbosity and a more complex bindings generation that could hinder its desirability. Not my call!
Typesafe GObject through static bindings
Inscription à :
Publier les commentaires (Atom)
Aucun commentaire:
Enregistrer un commentaire