[Kde-bindings] Splitting up the SMOKE library

[Thomas Moenicke]

On Tuesday 17 July 2007 14:19:02 Richard Dale wrote:
> On Tuesday 17 July 2007, Ashley Winters wrote:
> > --- Thomas Moenicke <tm at php-qt.org> wrote:
> > > The kalyptus generator should generate the qt_Smoke instance in
> > > smokedata.cpp only for the Qt smoke, for KDE smoke it should have
> > > a kde_Smoke instance which has a pointer to qt_Smoke. In case the
> > > inline methods of kde_Smoke don't find the index they can ask the
> > > qt_Smoke before it returns 0.
> > > Thus we can create a hierarchy of dependencies and don't need to
> > > touch too much in the implementations:
> > >
> > > + qt_Smoke
> > > +--+ qwt_Smoke
> > > +--+ kde_Smoke
> > >     +--+ whatever_in_kde_Smoke
> > > +--+ qscintilla_Smoke
> > >
> > > I think this way would follow the design currently implemented in the
> > >
> > > bindings, but i would like to hear the opinion of Ashley though.
> >
> > Yeah, a single-inheritance hierarchy should work. You first search your
> > "local" copy of smoke, and if something's missing you forward the
> > search to your parent.
> >
> > I went through my old code to try and refresh my memory of the issues
> > with combining Smoke libraries. PerlQt had a class already written for
> > merging Smoke instances, but it was never made to work.
> >
> > and the SmokePerl class declaration (with comments) here:
> > http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h
> >
> > And the implementation via the SmokePerlQt class here:
> > http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp
> >
> > It seems I even implemented a Smoke API for loading multiple libraries
> > from within Perl:
> >
> > http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smoke
> >pe rl.cpp?revision=1.1.2.16&pathrev=dev-3_0_0
> >
> > Apparently I went homeless before finishing that. It's too bad, cause
> > that was some good stuff. I can hardly remember how it works, now. :)
> >
> > 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.

And php-qt too, it should be ok to finish that.

> I think we just need a hash table called GlobalSmokeClasses
> of 'full_class_name => smoke instance' and load into it each time a new
> smoke module is loaded.

Sounds like a big thing in memory additionally to the smoke tables? 
Maybe if a class cannot be found in a smoke instance the request should be 
forwarded to one of the parents.
One basic question: do we want one generic superbinding that can deal with Qt 
only as well as KDE, Qwt, QScintilla etc? The problem I can see here are the 
container classes, anything else?

> When we look up a method for an instance we always provide the classname of
> the instance, and each instance already has which Smoke instance its class
> belongs to inside the 'smoke_perlobject' struct. So as long as we have the
> strings which give the names of superclasses that are not in the current
> Smoke instance, we can look them up the smoke instances of the parent
> classes when finding a method via the GlobalSmokeClasses hash. Then the
> classFn for a particular method won't always be in the same Smoke instance
> that the ruby/perl/csharp/php instance belongs to as now. But the code to
> call a method would be much the same.
>
> I don't think a particular Smoke module has to know which parent modules it
> has, only the individual classes need to know what their parent class names
> are as strings.

How exactly do you want too look up for them? The following method is defined 
in smoke.h and already has a comment hint:

    inline Index findMethod(Index c, Index name) {
        // TODO: If method is in a parent module, forward the call from here
        if(!c || !name) return 0;
        Index mid = idMethod(c, name);
        if(mid) return mid;
        if(!classes[c].parents) return 0;
        for(int p = classes[c].parents; inheritanceList[p] ; p++) {
            mid = findMethod(inheritanceList[p], name);
            if(mid) return mid;
        }
        return 0;
    }

So couldn't we add this line before 'return 0'?

	parentSmoke->findMethod(c, name);

Of course, if you want multiple inheritance you should ask Arnos pointer list 
for the right parent. I believe single inheritance would be much easier and 
the findMethod() even can stay inline. 
For multiple inheritance we need to think about a way not to produce crazy 
things, look at this example from Arnos mail:

         qt_smoke
       /                  \
kde_smoke  qscintilla_smoke
       \                  /
   whatever_smoke

Its hard do decide which path whatever_smoke has to choose to find something 
in qt_Smoke, isn't it? What happens if the structure is more complex:

another_smoke    qt_smoke
       /                 /          /
kde_smoke -------      qscintilla_smoke
       \                      /
   whatever_smoke --

Would be great if there is a clean solution, though :)

> Virtual method callbacks will need to have methods that are not in the
> current smoke module, but as far as I can see that should work ok at
> runtime, and it just makes the code generation harder.
>
> -- Richard
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings



-- 
Thomas