[Qt-interest] Global variables "the Qt way"

[Oliver.Knoll at comit.ch]

Harry Sfougaris wrote on Thursday, June 17, 2010 6:48 AM:

> ...
> It's probably not the intended use for it, but it seems to work for
> me. 
> If anyone know any problems this might create, I'd appreciate it...

One problem - apart from that you are "mis-using" the Qt Meta Property system ;) - I see with this approach is that the type safety is "weakened" by using a QVariant, that is you have to "know" the type of the global variable foo in order to call the proper QVariant::toXYZ() method, when you fetch the global value.

In many cases this might not be a big deal. But believe me, once you start using this kind of "weakening" the type safety in larger projects, people will copy this pattern - and I am talking about real world examples here ;)


I see this as a generic problem of any OO-language where you have a "root object" (in Java: Object, in Qt: QObject), and where people start to use idioms like:

  Map<String, Object> myDictionary = new HashMap<String, Object>();

and whenever you want to retrieve an actual value you have to cast, because "Hey, that's so cool, everything in Java is of type Object, so I can store /any/ object into my map!". Off course then you see code like:

  // Yes, I swear, I am totally sure that - at this place - "MyFooBar"
  // is of type FooBar! And if not, oh well... (and please, no one
  // change the type of "MyFooBar" anywhere else in the code, thanks!)
  FooBar fooBar = (FooBar) myDictionary.get("MyFooBar");

Okay, using QVariant doesn't require an explicit class cast, but when you store say a QDateTime and then say QVariant::toSize() you get an "invalid" QSize - so same problematic basically, the Qt approach a bit more "stable" in that you would not get a class cast exception (which in C++ would be fatal), but probably a problem later on (with the "invalid QSize").


Just my thoughts...:)
  Oliver
-- 
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22