[Kde-bindings] Splitting up the SMOKE library

[Richard Dale]

On Tuesday 17 July 2007, Thomas Moenicke wrote:
> 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/smo
> > >ke 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.
It doesn't sound too much memory to me - if we have 1500 classes with names 
10-15 chars long as the keys, and a 4 byte pointer as the values that only 
sounds like 30k (+ any hash table overheads) or so to me.

> 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?
The marshallers are held in a hash, with the type name as key, and the 
marshalling function as value. So when korundum is used, it adds the 
kde-specific marshallers to that hash on start up. The class that invokes 
methods doesn't have to know anything about qt or kde as that hash is global.

> > 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);
No, I don't think it goes there as that means the class has no parents. Maybe 
if 'inheritanceList[p]' is negative it means the class isn't in the current 
smoke module, although we can still look up its name. From the name we look 
up the Smoke instance and do a findMethod() call on that. findMethod() would 
need to return both a methodId and a Smoke instance. 

> 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.
I'm not sure we have to define any sort of relationship between the Smoke 
instances for the modules, we only need to know which module a particular 
class is in.  And the names of each parent of a class, whether or not they 
were in the current module.

-- Richard