Moving libkfacebook to extragear
Kevin Krammer
krammer at kde.org
Sun Oct 28 19:03:50 GMT 2012
On Sunday, 2012-10-28, Martin Klapetek wrote:
> On Sat, Oct 27, 2012 at 6:05 PM, Kevin Krammer <krammer at kde.org> wrote:
> > - FacebookJob(QString, QString) calls setCapabilities,
> > FacebookJob(QString) does not
> >
> > - Is the FacebookJob(QString) constructor really needed. It seems all
> > jobs need a path
>
> This is used (only) from FacebookGetJob, assumingly for querying multiple
> items, where just the ids are specified and no path is needed. I'll see
> what can be done about this.
Even FacebookGetJob and its subclasses set a path. FacebookGetIdJob for
multiple IDs sets the query as query item instead of encoding it in the path
itself, but it nevertheless needs "/" as path. So path is always needed, the
base class can always require it.
> > - the *Info classes seem to be normal data classes, IMHO they don't need
> > to be
> > QObjects but rather "value types"
>
> 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.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121028/f9e98427/attachment.sig>
More information about the kde-core-devel
mailing list