Hi, On Sat, Mar 26, 2011 at 1:20 PM, Patrick Ohly <[email protected]> wrote: > The last time I looked at QSparql, admittedly several months ago, it > didn't strike me as a particularly modern C++ API. For example, it had > lots of plain pointers where I would expect light-weight handles > instead. QtMobility feels a lot more modern in comparison. Just my two > cents, I have no idea what the goal is for QSparql.
I'm not the most informed when it comes to QSparql, but my understanding was that the aim was to provide interfaces fairly similar to (or the same as) QtSql, which (like the rest of Qt itself) often uses raw pointers. Mobility's approach of using wrapper handles isn't what I'd call the best idea, either, because it means that people can (and often do) try store pointers to them, and wonder why their code breaks when the underlying shared QContact goes away. See my recent patch to libseaside for a public example of this. > Is it meant to be part of Qt? Will there be an API review by Qt > developers before including QSparql in Qt? My understanding to this is 'yes, that's the objective', and obviously, 'yes; if that is the intention'. Qt doesn't just accept code without review. All of this aside, can't we agree that QSparql *is* one of the best APIs for using SPARQL with Qt right now, and aim on improving it from there if needed? Best regards, -- Robin Burchell http://rburchell.com _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
