From kde-bindings Thu Dec 11 04:40:33 2003 From: Ashley Winters Date: Thu, 11 Dec 2003 04:40:33 +0000 To: kde-bindings Subject: Re: [Kde-bindings] permanent URIs X-MARC-Message: https://marc.info/?l=kde-bindings&m=107111764531748 --- Richard Dale wrote: > On Wednesday 10 December 2003 03:02, Ashley Winters wrote: > > Howdy folks, > > > > > 'kdeui' is a scope here, even though it is just a library name rather > than a > namespace. Currently the C++ KDE classes which aren't in a namespace > are in > KDE:: for perl and ruby with any initial 'K' removed from the > classname. So > should that change to KDEUI:: for the classes in scope kdeui? Hmm. I'm not trying to propose that, but you did make me think about what I intended for the tag. In that example I used, every tag without a namespace: prefix is, by default, a cpp: tag for C++. So means , which is intended to represent C++'s definition of a scope. Initially, I intended to represent the actual heirarchy in C++. ::QWidget::setName means setName in QWidget in :: (the global scope). However, the "global" scope was pretty useless to me, since you have to include headers and link with a library before those functions are "really" in your scope, so claiming they are "global" didn't seem right to me. Hence, I redefined "global" scope to be the library object you have to link with in order to actually use the function. All the libc functions have a scope of &libc; and so on. But, that was wrong of me to do. I shouldn't take a well-defined term like "scope" and give it two meanings, especially when it's wrong. Why? An actual C++ "namespace foo {}" in global scope can be used in several libraries without conflict. Therefore, in what scope is foo? In lib1? In lib2? No, its scope isn't limited to any one object file. It's in an honest-to-goodness "global" scope. I should've used another tag to identify the library. So, moving on... > > > 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). > 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. 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. 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: 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! 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? 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. > 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. 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. Ashley Winters __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ _______________________________________________ Kde-bindings mailing list Kde-bindings@kde.org https://mail.kde.org/mailman/listinfo/kde-bindings