[Development] Why is QVariant::data() \internal?

[Konrad Rosenbaum]

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.


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160718/1f5ba5a1/attachment.sig>