[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Splitting up the SMOKE library
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2007-07-17 23:58:41
Message-ID: 532161.35693.qm () web50809 ! mail ! re2 ! yahoo ! com
[Download RAW message or body]

--- Richard Dale <rdale@foton.es> wrote:
> On Tuesday 17 July 2007, Ashley Winters wrote:
> >
> > From browsing through the code, it looks like smoke-qt and
> smoke-kde
> > didn't directly reference or inherit each other. They each filled
> in
> > the AUTOLOAD (method_missing for Perl) for the classes which they
> > respectively defined, and let the language method dispatcher handle
> > finding which class the method was defined in. Each class knew
> which
> > Smoke* object it came from, and each object knew which Smoke* it
> > belonged to.
> OK, I've had a read, and in fact some of that code is still in
> qtruby, and 
> then ported to qyoto. But I didn't understand the 'hasFire()' method
> quite - 
> why would only certain classes know which Smoke instance they
> belonged to?
> 
> class SmokeClass {
> ...
>     bool hasFire() const { return !(flags() & Smoke::cf_undefined); }

Ahh, that's due to each Smoke library needing an element in its class
list representing, for instance, QWidget. However, only the SmokeQtGui
library would have the implementation (hasFire() is true) of the class.
The hasFire() flag triggered actually importing the implementation into
Perl via registerSmoke():

void SmokePerlQt::registerSmoke(const char *name, Smoke *smoke) {
    hv_store(_registered_smoke, name, strlen(name), newSViv((IV)smoke),
0);

    // This will also need to handle the per-class initialization
    smoke->binding = new SmokeBindingQt(smoke, this);

    // Introduce all the classnames first
    for(int i = 1; i <= smoke->numClasses; i++)
	registerSmokeClass(SmokeClass(smoke, i));

    for(int i = 1; i <= smoke->numClasses; i++) {
	SmokeClass c(smoke, i);
	if(c.hasFire())
	    registerClass(c);
    }
} 

    void registerSmokeClass(const SmokeClass &c) {
	if(c.hasFire()) {   // we are the definitive smoke instance
	    SV *className = makePerlClassName(c);

	    SV *evil = newSVpvn((char*)&c, sizeof(SmokeClass));
	    STRLEN len;
	    char *name = SvPV(className, len);
	    hv_store(_perl_class_names, name, len, evil, 0);

	    const Smoke::Class *cp = &c.c();
	    hv_store(_perl_smoke_classes, (char*)&cp, sizeof(const
Smoke::Class*), className, 0);
	} else {		// our class must already exist
	    // TODO: search the smoke hierarchy and find the Smoke instance
	    // which has the fire, then cache it in _perl_smoke_classes
	}
    }
    void registerClass(const SmokeClass &c) {
	installIsa(c);
	installAutoLoad(c);
	if(c.hasConstructor()) {
	    installNew(c);
	    installConstructor(c);
	}
    }

The TODO above is probably not necessary, since each Smoke library
would insert its own classes into the global mapping, like Richard
suggested. Perhaps it was meant as a reverse mapping from the stub
(sans fire) Smoke/classid combination to the genuine implementation?

Some mechanism like that needs to handle the situation where a KDE
class has the prototype:

  QMenuBar *getMenuBar() const;

The KDE smoke library would return a QMenuBar classid which is valid in
its OWN smoke lib, but not in QtGui's smoke lib. Any attempt to call a
method on that object would fail. I tried implementing some central
object management in smokeperl.cpp (createObject(), rememberPointer(),
and various shortcuts), but I'm not sure how close I ever got to the
mark.

- Ashley Winters


 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]