[Kde-bindings] Readable GCC dump parser

[Richard Dale]

On Saturday 02 August 2003 21:07, Ashley Winters wrote:
> --- Alexander Kellett <lypanov at kde.org> wrote:
> > On Sat, Aug 02, 2003 at 03:21:36PM +0200, Alexander Kellett wrote:
> > > okay. just to check if i've got this right.
> > > kalyptus would be partially replaced by this
> > > then smoke would be modified to use the xml api.
> > > and in principle perlqt/kde and *ruby would not
> > > really require all that much work other than a
> > > few namespace changes and a ton of data type
> > > (de)marshallers?
>
> I want to split Smoke into 2 pieces, effectively into Smoke and a
> Mirror.
Good name! Light bouncing off a mirror is like a message being redirected by a 
proxy instance. Don't know what it stands for though - so many R's.. 'Message 
Invocation Redirection..' um er..

> The "flaw" in Smoke's design is that it never forces Qt to work down at
> the lowest-common-denominator, C. It works at a higher level, which is
> all I needed for dynamic language like Perl (and, it seems, without
> modification for Ruby).
I think that was only a flaw for C# which had 'magic marshalling' for a C api
or something. For other languages you could use the simple existing SMOKE 
interface with C wrappers.

I think there are at least five sorts of languages (I'm personally really only 
really interested in the first two categories):

1 - Fully dynamic - perl, python, ruby, Smalltalk

2 - Semi dynamic - java, C#, Objective-C

3 - Semi dead - C++ with moc

4 - 'Dead' :) - Eiffel, Ada, Object Pascal, FORTRAN

5 - 'Weird' - Haskell, prolog

For, type 1 languages we're already there, just need a kde version

For type 2 languages, I'm not sure if all of smoke could be used or just the 
mirror part. For java, to use that message forwarding part of smoke, it would 
mean creating the complete class hierarchy as dynamic Proxy interfaces. Don't 
know if that's technically possible, but it would be fun finding out.

Objective-C is really just as dynamic as Smalltalk, but the distinction for 
bindings writing is that you need to generate a header files for the 
Objective-C proxy classes, if you want to avoid a load of compile errors. 
Those two languages also need the argument names to construct the equivalent 
of a method name, which the current SMOKE runtime doesn't have.

For type 3, for C++, KDE is already on top of that one :)

For type 4, I think you would need a moc preprocessor equivalent. How do you 
do the equivalent of 'responds_to' with them?

Type 5, weird. I might look into interfacing with prolog sometime. I've been 
reading about Haskell, as people were talking about it KDE dot news - 
nightmare! But someone has interfaced it to the wx toolkit, so it might be 
possible to do something with it.

> While this serves the purposes of Qt just fine, it does squat for the
> goals of KDE, which needs the kind of flexibility to be used from
> non-C++ compiled languages. I provided nice innovations (like virtual
> function support and signal/slot voodoo) without making them accessible
> to compiled languages.
>
> So, the new Smoke will take an XML API for Qt/KDE/Whatever and flatten
> it out into a C library, and then provide a separate library to make it
> accessible through marshallers and such to dynamic languages like
> Perl/Ruby/Python.
Well, as long as it doesn't end up too huge. 

> The Mirror library will provide the introspection into Smoke needed for
> the autoload trickery we do to avoid having to declare all the Qt
> functions. Essentially, it's the new name for the
> function-lookup-trickery that Smoke does now. It will just be generated
> from the XML file, instead of Kalyptus.
I think non-scripting languages still need to extract stuff from headers like 
comments, to combine with the xml data extracted from the translation unit. 
And generation .java classes or Objective-C headers is going to be language 
specific.

-- Richard