GNOME.org
 

Re: gtk2 news

On ons, 2002-09-11 at 00:18, muppet wrote:

Christian Borup wrote:


On man, 2002-09-09 at 18:43, Scott Smith wrote:


* After wrapping the libraries:

While basic wrappers for the libraries would be nice,
all we'd be left with is perl code like:

   use libgtk;
   my $winptr = libgtk::gtk_window_new();
   libgtk::gtk_window_set_title($winptr,"My Title");



This would be silly. 
XS will do all the wrapping for you.
You just give the XS compiler a couple of hints, and the methods will be
placed in the right packages.

The hints in this case would be:
MODULE = Gtk::Window    PACKAGE = Gtk::Window   PREFIX = gtk_window_

This makes gtk_window_new() become Gtk::Window->new() in Perl.



careful ---- the XS function would have to know that a string argument 
was coming.



Mea Culpa :-)
But I'm really only guity of a bad example...
I should not have used a constructor as example...
 

GtkWidget *
gtk_window_new ( class, type=GTK_WINDOW_TOPLEVEL )
        char * class
        GtkWindowType type
    CODE:
        RETVAL = gtk_window_new ( type );
    OUTPUT:
        RETVAL


in most cases such a trick isn't necessary, because the object itself 
supplies the class.


This trick is indeed needed, to not break the rule of least surprise.
Users expect these two lines to be equivalent (the first one is not
safe).
        $w= new Gtk::Window;
        $w= Gtk::Window->new();

And it should just work as people expect.


as you pointed out, this overcomes the problem of defining the method 
interface from the functional interface --- they are one and the same.


You said it better :-)


Again XS will do this translation for you. This is what typemaps are
for.

Using a hashref is actually a pretty neat idea. If the plain C pointer
was used the object would be opaque to the Perl side of things. So
subclasses would have nowhere to put object private data (I do know
about set_data/get_data - but those present other problems).



another reason to use a hashref containing the C pointer instead of a 
plain blessed C pointer as the type is preventing accidental destruction.


i've run into this problem before when using blessed C pointers as objects:

    sub dosomething {
        my $object = shift;
        my $childobject = 
$object->get_child_object_from_pointer_held_deep_within_object;
        ...
    }


note that i'm not creating a new widget for $childobject here --- a new 
object is being created from a pointer to an exsiting object.

at the end of the block, since $childobject is local, it's DESTROY 
method will be called...  if you don't have proper reference counting 
going on, this will actually destroy the object right there, which can 
wreak havoc on your program.

if you keep the C pointer in a hash ref and use the hash ref as the 
object, the GObject reference counting can continue normally and the 
objects don't die early.


There is no win here the hash goes out of scope just as the opaque
pointer, and is thus destroyed...


then again, am i full of crap? what if the typemap used GObject 
reference counting to keep the objects alive?  is that a better 
solution, or are there still holes there?  you still run afoul of the 
fact that you might already have an perl object for that GObject...  (in 
my opinion, this is the messiest aspect of the whole shebang.


Using the GObject ref count would be best I think, the old binding
handles this.

./borup
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]