[Kde-bindings] Re: [Kde-java] Re: GCJ (Re: Build system for KDE4)

[Ashley Winters]

Richard,

I looked at the KDE source and got an idea how to grab the comments
without parsing. I'm already fiddling with the pre-processor output
using perl (from my last e-mail), so how about we get it to convert the
javadoc comments into C strings for gcc?

Example:
    /**
     * The same as the above constructor, but with a KGuiItem providing
     * the text and icon.
     *
     * @param item The KGuiItem with the label and (optional) icon.
     */
     void func(...);

Becomes:
    // we need to encode spaces, or else the -fdump parser dies
    void __SMOKE_COMMENT_123(const char *comment = "/**%0A"
"%20%20%20%20%20%20*%20the%20text%20and%20icon.%0A"
.....*/");
    void func(...);

GCC dumps the value of default arguments, and I could save the default
argument to __SMOKE_COMMENT.XXX() functions and attach them to the next
function declared (in document order).

The only parsing required would be m,/\*\*.*?\*/, match.

Also, the XML output includes all the argument names. We could
implement named args!

$foo->method(-arg => "value");  # perl5
foo.method(:arg => "value");    # ruby
foo.method(arg:"value");        # python
$foo.method(:arg<value>);       $ perl6
foo at method ~arg:"value"         # ocaml

We just need to prod the trolls to provide names for all the arguments
we want to use. :)

Ashley

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:

> From the kde-java mailing list:
> 
> On Friday 17 June 2005 10:44, Richard Dale wrote:
> > On the kdebindings at kde.org list, Ashley Winters is discussing his
> ideas for
> > Smoke v2. I would much prefer all new language bindings to use the
> same
> > library for KDE 4. I don't think this affects our recent
> discussions on the
> > look of the api, to me that seems independent of whether or not to
> use JNI
> > or CNI, and/or the Smoke library. He is proposing generating
> bindings via a
> > translation unit dump of the compiled object code to xml, followed
> by XSLT
> > transformations to generate the C++ code for the Smoke lib. It does
> lose
> > the comments in the headers though, and I still think we need a
> header
> > parser to generate the javadoc comments from the doxygen ones. Or
> to look
> > for methods marked with a '@deprecated' tag, and not add them to
> Smoke
> 
> -- Richard
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com