[Kde-bindings] permanent URIs

[Richard Dale]

On Thursday 11 December 2003 04:40, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > >   <!-- The function-type has no knowledge of parameter names
> > >        or default values. Since PerlQt-4 will support calling
> > >        methods like $pb->addButton(-text => "Okey Dokie"), we
> > >        need to elaborate on what arguments can be passed here -->
> >
> > So the argument names will be available in the Smoke v2 runtime
> > (essential for
> > Objective-C and Smalltalk bindings), even though they're not part of
> > the URI?
>
> Yes. One reason they're not in the URI is expedience -- too many
> functions in Qt don't have argument names, and will be filled in using
> "arg1", "arg2", arg3" dummy names. If enough people start using
> parameter-by-name argument passing for Qt, the Trolls may add (or
> accept patches adding) parameter names to all the headers, which would
> otherwise change the URI (a bad thing).
OK thats fine, I agree it shouldn't be part of the URI - too fragile.

>
> > I can't find any books on rdf in my local book shops, if I could read
> > O'Rielly
> > 'Practical RDF' it might give me some idea - I haven't quite 'got it'
> > yet.
>
> Hrm. Never read that. Don't know if it's good. I like the word
> "Practical" though. There are enough "theoretical" documents on RDF
> floating around on the web to scare people off.
I think I'll go and order that book then, and see if there are any ideas that 
could be used as a starting point.

> One of the most insightful (for understanding) uses of RDF is for
> Creative Commons licenses.
>
> http://creativecommons.org/technology/metadata/implement
>
> It's a way of programmatically specifying the ways in which an author
> permits you to share/modify their works.
Just had a look at that - it does seem a good example of RDF use, and they 
explain it very well.

> Another useful thing about RDF is that there's no one definitive source
> for information about a subject. Just because I make lots of statements
> about &qt;QWidget doesn't mean you can't make some more. In fact, this
> is useful from an implementation standpoint, since the Qt metadata
> extraction is separate from the C++ parsing.
>
> After reading in that file from my first email, there can be another
> file containing the signal/slot metadata as well:
>
> <rdf:Description
>   rdf:about="&qt;QButton::pressed()"
>   qt:signal="pressed()" />
> <rdf:Description
>   rdf:about="&qt;QPushButton::setOn(bool)"
>   qt:slot="setOn(bool)" />
>
> That last one made an assertion that "&qt;QPushButton::setOn(bool)" is
> a qt:slot named "setOn(bool)".
>
> Slots are not unique to Qt. Gtk and the C++ Boost library have them as
> well. But those are different implementations. When we speak about
> slots, we mean a *qt* slot. Uniquely. If you mean a gtk signal, you had
> better say gtk:signal="clicked".
>
> How do we know that a qt:signal is different than a gtk:signal? Because
> those attribute names actually point to a URI. For instance, qt:signal
> could point at http://rdf.kde.org/qt/3/signal and in that file there
> would be a human-readable description of what the heck a "signal" from
> Qt is! That's one of the beauties of RDF. In the end, every tag you use
> to describe something is *a document* which defines how it should be
> used, the means by which you should be using it, and what meaning you
> should take from seeing it be used.
>
> If my http://foo.bar.com/jahqueel/gay describes itself as meaning
> "happy, joyful", that's what it would mean if I applied it to myself.
> It doesn't mean what *you* think it means. Tt means what I, the owner
> of http://foo.bar.com/, say it means!
A qt signal has something in common with a gtk signal, but the two uses of the 
word gay (in the homo: and oldfashioned: namespaces?) don't have anything in 
common. I don't know if that's good or bad, a feature or a bug. You would 
need to add an intermediate namespace to somehow link a gtk signal with a qt 
one I suppose. And that wouldn't be possible with the modern and old uses of 
'gay' - they don't have anything to do with each other.

> Since the Qt metadata and the C++ header info are in different files
> (with different URLs), you can use them separately, or combine them
> together since they reference the same URIs for the function names.
>
> > Maybe there could be a service that would be useful to programmers
> > who use
> > the C++ api - it isn't only useful to just bindings. So some sort of
> > interesting application of the rdf for C++ programmers like online
> > documentation/wiki, that would make them interested?
I was thinking of extracting the doc comments from classes, methods, enums etc 
using kalyptus, converting the kdoc tags and html codes into some common 
format, and putting that text into a perl hash with a key of the URI. That 
would make it easy to combine the doc comment data with stuff extracted from 
the translation unit, or anywhere else. And then do something similar with 
the Qt doc comments in the sources, to convert them to the common format.

> DCOP for every function without dcopidl? :)
>
> In reality, I'm not offering anything that isn't already in the header
> files. It's hard to offer much to a static language.
To me, it seems to be about thinking up several small ways to use the URIs and 
RDF, and then hoping to get it to link up into something bigger. There's no 
point in having a common vocabulary if you only have one use for it, so I 
don't think the starting point can be a single large 'killer app'.

> > Can a wild card search be made on the rdf defined api, such as
> > 'return all the
> > set* method names for this list of classes'?
>
> This is a matter of implementation. There is no XPath for RDF, or any
> other standard way of using it. It is... whatever we make of it.
> Daunting.
I asked about finding set* methods, because I'm thinking about doing something 
with 'Aspect Oriented Programming' with the java bindings. In Smoke terms, 
when a method is to be called, it involves pushing the arguments onto the 
Smoke::Stack as usual, and then possibly calling it more than once. Either 
the usual C++ method or some custom code in java added via a mixin (an 
'advice'). It seemed RDF might be a good way of describing the rules. For 
instance, I might want to make all set* methods for QWidget log when they've 
been called, so I would write a java method called 'myLogger()'

qt:QWidget    java:advice    'myLogger()'
qt:QWidget    java:apply      'set*'

But I think that rdf would only be used with the java binding, it wouldn't 
make sense anywhere else. So in that case it might be better off as a normal 
kde config option stored as strings using KConfig etc.

> However, one the simplest implementations of RDF can be done with a SQL
> database containing only 3 columns. Throughout RDF literature, you'll
> see those "columns" named "subject", "predicate" and "object".
>
> For instance, my XML file boils down to a set of
> subject/predicate/object triples which looks something like this:
>
>     subject       | predicate | object
> ------------------|-----------|--------------------------
> kdeui:KPushButton | rdf:type  | cpp:Class
> kdeui:KPushButton | cpp:name  | "KPushButton"
> kdeui:KPushButton | cpp:scope | kdeui
> ...
>
> That is the RDF "model". A group of triples like that can encapsulate
> all sorts of information using URIs as the elements. The W3 also has a
> decent way of describing it: http://www.w3.org/TR/rdf-primer/
>
> If we use a SQL database, such queries become quite possible with the
> right select statement. Of course, there are other ways to implement
> it, but that's just one example showing how it *is* possible.
>
> My SQL knowledge sucks, but wrap your brains around this for a query,
> Richard:
>
> ; find all members of KPushButton and QPushButton named set*
> select t1.subject
> from rdf as t1, rdf as t2
> where
>   t1.subject=t2.subject and
>   t1.predicate="cpp:scope" and
>     (t1.object="kdeui:KPushButton" or t1.object="qt:QPushButton") and
>   t2.predicate="cpp:name" and t2.object like "set%"
>
> Of course, we'd never use strings for that. Just an example. An
> untested example.
Hmm, this looks to me like an unsuitable use of SQL - because you have 
heirachies to describe (classes within classes), and it doesn't usually work 
well with trees..

-- Richard