On Sun, 18 Oct 2009 09:49:55 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> Paolo Bonzini wrote: > > On 10/18/2009 04:06 PM, Luiz Capitulino wrote: > >> Integration with QObjects is a killer feature, I think it's the > >> stronger argument against grabbing one from the internet. > > > > Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder > > on top of it soonish (I still think it's best if JSON encoding lies in > > QObject like a kind of toString). If we'll need the asynchronous > > parsing later, we can easily replace it with mine or Vincent's. > > One thing I want to add as a feature to the 0.12 release is a nice > client API. To have this, we'll need message boundary identification > and a JSON encoder. I'll focus on the message boundary identification > today. > > I'd strongly suggest making the JSON encoder live outside of QObject. > There are many possible ways to represent a QObject. Think of JSON as a > view of the QObject model. The human monitor mode representation is a > different view. I agree. QObject's methods should only be used/needed by the object layer itself, if the problem at hand handles high level data types (QInt, QDict, etc) then we need a new type. The right way to have what Paolo is suggesting, would be to have a toString() method in the object layer and allow it to be overridden.
