[Kde-bindings] Splitting up the SMOKE library

[Richard Dale]

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/smokepe
>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. 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); }

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. 

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.

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