On Sun, Oct 28, 2012 at 8:03 PM, Kevin Krammer <[email protected]> wrote:
> > > This is for the parsing purposes - the library uses QJson parser/mapper, > > which automagically maps the received json data to qobjects, otherwise > > there would have to be manual parsing everywhere (and the facebook jsons > > are huge), which means more code, more error possibilities, more > > maintaining requirement and worse readability (compared to two lines > QJson > > mapper). So I'd like to leave this one as is. > > I haven't had a look at the QJson library internals (yet), but from its > usage > it looks like that it is only using instances of those QObject classes to > provide a convenient mapper of map keys to conversion functions (the > property > setters). > > This would make them an internal implementation detail, something more > convenient than manually writing a mapping of string to function pointer > but > also just private. > > As I said I'll have a look into QJson, but unless I am gravely mistaken it > only needs such QObjects as a generic accessor API, not as the actual data > object. > Thanks. I fixed all the issues you pointed out except this one. Also I checked for the naming and here's what I found [1]: 6. You may not combine our Brand Assets, or elements of our Brand Assets, with your own name or mark or generic terms. So if "lib" is a generic term, "k" is sort of our mark, I guess "libkfacebook" is pretty much off limits, right? Either way, we might be just better off changing the name and rest calm. I'm thinking going in steps of "libkgapi" - "libkfbapi". Thoughts? [1] - https://www.facebook.com/brandpermissions/logos.php Cheers -- Martin Klapetek | KDE Developer
