[Development] Wishes for C++ standard or compilers

[Olivier Goffart]

On Montag, 20. März 2017 11:27:44 CET Konrad Rosenbaum wrote:
> Hi,
> 
> On Mon, March 20, 2017 08:20, Olivier Goffart wrote:
> > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
> >> The name is necessary for compatiblity iwth other languages.
> > 
> > Can you elaborate?
> > In QtScript or QtQml, the name is only used for error message, or for
> > compatibility before the QMetaObject was in the QMetaType.
> > Types that can be used directly needs to be registered with functions such
> > as
> > qmlRegisterMetaType
> > 
> > I see many use in QtDBus but I suppose if it falls in the category of
> > types
> > used for signals and slot which could be registered by moc.
> 
> There are more bindings than just QtScript and QML.
> 
> Any dynamic binding that does not want to force the user to register
> again(!) every single type that could possibly appear somewhere in the API
> needs to know the name. At least if it wants to be compatible with itself
> between versions and platforms. Type IDs can change in between versions of
> a program or even if only an underlying library is updated.
> 
> For example: I'm currently writing a utility that taps into a Qt program
> without modifying the program itself and allows to inspect objects and
> properties (something technically similar to GammaRay). In order to
> serialize and deserialize the properties of objects I need to be able to
> reliably determine the type of those properties on both sides and be able
> to reconstruct them, or at least to be able to determine whether I need to
> fall back to a string representation. For user types the name is much more
> reliable than the ID.
> 
> In other projects I've used the MetaType system to expose type names of
> data stored in a QVariant to Tcl based scripts, a formula parser with
> dynamic typing, a template rendering system, or debugger utilities.
> 
> The common theme among those was that I did not know what types my utility
> would face at the time I wrote the utility accessing QVariant. And those
> utilities usually work rather invisible to the libraries originating the
> types used in them and vice versa.
> 
> In short: being able to get both an ID and a name for a type stored in
> QVariant makes a lot of magic possible that would otherwise require major
> blobs of glue code or it would otherwise simply be so inconvenient to use
> that it wouldn't be worth bothering.

Yes you are right, the name is still nice to have for serialization.
For QObject properties, moc can (and already does for some types)  register 
the type name.

It's true that you cannot serialize a type if you don't have some persistent 
identifier such as the name.