On Sa, 2011-03-26 at 13:39 +0000, Robin Burchell wrote: > 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.
Yes, I know. I was just wondering whether QSparql follows that approach intentionally and whether that is still considered good style for newly designed APIs. QtMobility did things differently, and I personally prefer that. > 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. I wonder whether this bug isn't even a case in *favor* of the QtMobility approach: if the app had used handles as intended by the API instead of falling back to pointers (and then presumably not maintaining ownership of these pointers correctly), then the QContact instance couldn't have gone away unexpectedly. > 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? I don't think there is any doubt that QSparql is the way forward. I raised the question about reviewing the API a while back when QSparql was proposed for MeeGo, but didn't get an answer at that time. It is reassuring that this has happened, as Thiago said in his email. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
