[Kde-bindings] Re: [Kde-java] Re: GCJ (Re: Build system for KDE4)

Ashley Winters jahqueel at yahoo.com
Sat Jun 18 09:21:15 UTC 2005


--- Simon Edwards <simon at simonzone.com> wrote:
> On Saturday 18 June 2005 04:35, Ashley Winters wrote:
> [Smoke and parsing C++ header and gcc stuff snipped]
> 
> May I insert a dumb but related question, where does garbage
> collection for 
> language like Python, Ruby etc fit into Smoke and all this?
> 
> just curious,

I was going to write out an even long answer than this, but short is
probably better. :)

Smoke lets the bindings hook into an object's virtual destructor. That
way, they can know when the object gets deleted (window closed) by Qt,
and act like it's holding smart pointers which go undefined when the
object disappears.

Also, when an object leaves language scope, we call whatever passes for
its parent() function to see if it's "owned" by another object. If so,
we override the language's object destruction and hide the object in
it's parent. That way, if the object ever shows up again, its state
remains the sane. For example:

sub foo {
    my $m = new QMenuBar;
    $m->{my_data} = "a value I want to keep";
    setMenuBar($m);
}   # $m is gone, but the menubar got stored in this

sub someEvent {
    # if we retrieve the menubar later, we get the original object
    blurfl(menuBar()->{my_data});
}

If the object has no parent, the object will get deleted by the binding
when all variables to it go out of scope and the language calls the
finalizers. In Perl5, that's deterministic. For other languages, it
happens whenever they feel like it.

Ashley Winters

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the Kde-bindings mailing list