On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote: > On 25/02/2013 17:25, Sascha Cunz wrote: > > Why would a function that is "potentially useful on more than one > > platform" go to platform extras? > > Because it's working on native types (more than just one) and encoding > all type names into the function name would be strange. The same > function name could make sense on a different platform. Note that I'm > talking about the function name, not the full signature.
Actually, i don't get this: If there is some feature that is reasonable to have on more than one platform, then Qt should probably abstract it with a Qt-ish API, right? That's at least how things worked for ages. In terms of Qt 5, this would probably result in an add on QtFooFeature, which is tagged as available for the platforms it works upon. If on the other hand there's a complex feature that is bound to one platform and it is not yet covered by a add on on it's own, this feature should be properly abstracted into a Qt-ish Api, too, right? Properly abstracted here refers to a class inside the add on's namespace. As far as i can see, this leaves two kinds of functions that could possibly become members of the "Qt"- or the addon's namespace: - Functions that extent the API of an already abstracted feature (i.e. QString or QImage) with platform specific code. These would provide platform specific additions to the feature itself. If there is one of them, they could as well go to a namespace; If it is foreseeable that their number will increase by time, they should probably go into a class; c.f. qt4's qt_mac_XXX stuff for unified toolbar support. - Functions that convert Qt objects into their native pendant. These don't introduce new "features" themselves. They just provide compatibility to additional features of the native platform. These usually don't overlap in signature. Sascha _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
