[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klink
Subject:    node specializations vs. nodes with properties
From:       wheeler () kde ! org (Scott Wheeler)
Date:       2004-11-09 6:11:29
Message-ID: 200411090610.46593.wheeler () kde ! org
[Download RAW message or body]

Ok, here's the other topic, and in a similar vein with the more flexibility 
stuff.

Right now we've got several subclasses of KLink::Node to represent various 
node types -- i.e. a word, a file, a URL, etc.

I'm now leaning towards ditching that and moving towards a property system 
where we'd have a fixed number of types, i.e. integer, float, string, binary 
data, whatever (mapped to a QVariant, likely).

And properties would be of one of these types and could then be associated 
with a node, i.e. a URL would be a string and could be associated with a 
node, as could be a file name, a word is just a property, etc.

We'd probably want the same thing for links, probably using the same data 
types -- here for instance an anchor would be one type of property, an 
integer word position another.

So, for example:

| ====================|
| Property Data Types |
| ====================|
| String              |
| Short               |
| Int                 |
| Long                |
| Unsigned [...]      |
| ByteArray           |
| [...]               |
|=====================|

|=================================|
| Properties                      |
|=================================|
| TextAnchor (String)             |
| BinaryAnchor (ByteArray)        |
| WordPosition (Unsigned Integer) |
| Word (String)                   |
| URL (String)                    |
| FileName (String)               |
| [...]                           |
|=================================|

Then you would have node ID 42 with a TextAnchor, a URL and whatever else.  
And node ID 256 with a Word and a WordPosition, etc.

The KLink interface would be something like:

QStringList properties() const;
QVariant property(const QString &name) const;
QVariant setProperty(const QString &name, const QVariant &value);
static KLink::NodeList nodesWithProperties(const QStringList &properties);

(Actually we'll probably need some better notion of a node set that works well 
with intersections and such and knows a bit about how it was created so that 
such can be fed back into database queries, but that can come later...)

And so on...

As such could then have more of a free structure that would allow us rather 
than saying "give me all of the KLink::FileTargets to "give me every node 
with a file name" or instead of KLink::Word having "give me every node with a 
word property".  Most of the practical cases of this that I know of at the 
moment would be mapped to the concrete examples now in the API, but I think 
this would provide something (a) easier to implement and (b) more future 
safe.

Again, I'm quite tired at the moment, so this probably isn't as clear as it 
could be -- let me know if this isn't making sense.  Thoughts?  ;-)

-Scott

-- 
There is more stupidity than hydrogen in the universe, and it has a longer 
shelf life.
--Frank Zappa
[prev in list] [next in list] [prev in thread] [next in thread]