[Kde-bindings] Using a custom RealProxy to implement a C# SMOKE adaptor

[Richard Dale]

On Thursday 21 August 2003 09:40, James Michael DuPont wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > On Thursday 21 August 2003 04:56, Marcus wrote:
> > > I'm so lost with all this SMOKE stuff lately, but I do think that
> >
> > using
> >
> > > SMOKE with C# is a huge mistake.
> >
> > It doesn't feel a mistake to use SMOKE for the QtJava project. Why do
> > you
> > think it would be a mistake for C#?
>
> I think that the whole idea of extracting data from the compiler
> instead of parsing c++ is great.
>
> By using the compiler only one person needs to have, you can extract
> all the relavant facts from the source code, and publish those facts.
>
> The facts about qt dont change very often, so only marginal changes are
> needed.
>
> The issue of generating binding from those facts may need special tips
> and tricks that augment the basic facts, but those dont change hardly
> ever.
>
> As far as I know, that is the goal of smoke? Markus with all respect, I
> disagree with you if that is what you meant. Also I know you were
> working on various parsers and generators that are competition to this,
> respect to you on that, but I still feel that writing another c++
> parser is not a productive thing to do. Maintaining it is also a
> problem, why not use the gcc?
I don't think the parser issue is relevant to whether or not the SMOKE 
*runtime* is a good thing. Currently SMOKE mk 1 uses the kalyptus perl header 
parser for generating both SMOKE itself, and the java wrappers for the 
Dynamic proxy calls. SMOKE mk 2 will use the gcc extraction stuff, and QtJava 
might use Doxygen/XSLT or JDOM or XOM or .., instead of kalyptus, to generate 
the .java sources. So if SMOKE was generated via gcc extraction or via a C# 
XML script that wouldn't be the most important issue.

I'm interested in whether creating a facade of custom RealProxy's to allow all 
C# calls to be funneled into a single Invoke() is a good thing. That Invoke() 
needn't even call the SMOKE library - it could be some other 'black box' 
created in a different way. Is dynamic method overloading resolution and 
despatch a problem with respect to efficiency compared with the normal static 
despatch approach in language bindings. Once, you had built a RealProxy based 
facade in C#, it could be easily used for all the other .NET languages.

-- Richard