Hugs,
C, J and P

Yes, concrete syntax is planned but not for the next weeks. I’m currently working on XMI serialization and some OCL parser/QtScript/XQuery infrastructure,
since those feature have higher priorities by now.

Thanks,

good luck!

regards
Jan

QtUml::QElement * element = property.read(element).value<QtUml::QElement *>();

and

QtUml::QNamedElement * namedElement = dynamic_cast<QtUml::QNamedElement *>(element);


QtUml::QElement * element = property.read(element).value();


and

QtUml::QNamedElement * namedElement = dynamic_cast(element);


thanks for the explanations! Yes, the “abstract property” was just an idea of how moc could be extended.

Regarding the QVariant topic, what I mean is that you only need QVariant to access the property value via QMetaProperty. In that case, I guess that the QVariant is initialized using the type given when declaring Q_PROPERTY and it would be sufficient to always use the base type (QElement). You only need then a cast to get a pointer to a derived class (which is anyway needed).

QtUml::QElement * element = property.read(element).value();

QtUml::QNamedElement * namedElement = dynamic_cast(element);

But I probably missed something

Benoit.

Yes, Q_GADGET would be an option, but I couldn’t find any use of Q_ABSTRACT_PROPERTY in qt5 codebase. Does it already exist or are you wondering some moc extension ?

Regarding QVariant issue, you can’t write a

v.value<QElement *>()

if you have created the QVariant by writing, for example:

QVariant::fromValue<QNamedElement *>(...),

provided that QNamedElement inherits QElement. That only works in Qt5 AND if all involved objects inherit from QObject. Of course, I’m also assuming you aren’t willing to write some weird code like:

QNamedElement *element = dynamic_cast<QNamedElement *>((QElement *) v.data())

I’ve made some improvements on client-side, by defining a QtUml-specific smart pointer. I’ll blog about that soon

Thanks for reply

One of the drawbacks here is that it requires to explicitly cast to a base class in order to access its properties and methods (if I understand it correctly). The main advantage is that it can properly handle multiple inheritance, even for concrete objects, while keeping the derived class free of stub-methods…

I guess that moc support would be very tricky and maybe even involves extending QObject, too.

Another idea would be to have some kinds of abstract properties, being also supported by non-QObject types (with additional moc support using for example Q_GADGET).

That could be something like:

class QElement // not a QObject!
{
Q_GADGET
Q_ABSTRACT_PROPERTY( QString name READ WRITE )
…

protected:
QElement();
};

The QMetaProperty objects still belong to the concrete class (“QPackage”) but the meta object could provide information about the base class the property belongs to, while moc could generate an error when an abstract property is not implemented.

Regarding the issue with QVariant (which is the reason why you are “forced” to use QObject), I did not really get it. Wouldn’t it be working if the namespace_() method returned a QElement* (instead of QNamespace*) and the type had been checked with a dynamic_cast?

Anyway, if there is absolutly no way to avoid using QObject for the base classes, your solution is smart and seems to be the best, far better than using stub-methods… There might be some alternatives using templates, but it would make many developers (like me) run away

See: http://qt-project.org/doc/qt-5.0/moc.html#multiple-inheritance-requires-qobject-to-be-first

I’m sorry, but someone had to say it

**meanwhile, aleix waits to see the review request**

I’ve already updated the technical documentation [1]. So, they should have a decent place to start.

Good Luck

[1] http://techbase.kde.org/Projects/Nepomuk

Thanks Tumate!