On Montag, 18. Juli 2016 23:15:22 CEST Konrad Rosenbaum wrote: > Hi, > > On Monday 18 July 2016 07:59:21 Jędrzej Nowacki wrote: > > On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote: > > > I am currently interfacing two libraries that only have QVariant in > > > common, most of the (value) types getting exchanged are either Qt > > > containers or Q_GADGETs. > > > > > > I was relatively quick to realize that I needed the QMetaType and > > > QMetaObject of these objects, but it took me pretty long to find out > > > that I can use QVariant::data() to get at the void* that I need to > > > access properties and Q_INVOKABLEs. > > > > > > Is there a particular reason that QVariant::data() is classified as > > > \internal or would a documentation patch be accepted? > > > > Mostly because it should not be needed. > > I can see why it should not be needed in 95% of situations. But there is > this tiny little fraction of cases in which QVariant is the only commonality > between interfaces. Esp. if those interfaces are supposed to be generic, > non-related and exchangeable. > > I'd argue it is needed often enough to merit some documentation with a big > fat warning for the other 95% of cases. > > > Why can't you use https://doc.qt.io/qt-5/qvariant.html#value or > > https://doc.qt.io/qt-5/qvariant.html#qvariant_cast ? > > The library that is looking into the QVariant is a generic > calculation/templating engine that uses QVariant to exchange data with > whatever outside caller is using its services. > > It does not know what kind of data types the calling code uses - all it can > assume is that it gets property names to find the values it is really > looking for. It does not even know why it is being used. > > The data source may be the calling code or it may be a completely unrelated > library. > > Example: > Lets assume the engine is configured to work on strings and it gets the > formula {'I am ' + my1.name} and "my1" is configured to be a pointer to a > QObject-derived class or a Q_GADGET. The formula itself will usually come > from some kind of configuration (otherwise: what's the point!). What the > library code does is parse the formula, delve into the QObject or gadget > behind "my1" and retrieve the property "name". > > For some use cases demanding that structured types are QObject is simply not > feasible since the remainder of the use case may demand value logic (in my > current specific case it represents data exchanged over the network). > > Writing a formula parser is complex enough for me to definitely not wanting > to tie it to one specific application - hence I do not want it to know the > specific structured types - I want it to explore those types through some > kind of reflection - turns out QMetaType/QMetaObject is a wonderful way of > doing this. >
I think indeed, with the recent Q_GADGET change, there is indeed a reason to document QVariant::data/constData or QMetaType::IsGadget -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
