On Mon, 19 Oct 2009 09:17:38 -0500 Anthony Liguori <aligu...@us.ibm.com> wrote:
> Luiz Capitulino wrote: > > On Sat, 17 Oct 2009 08:36:06 -0500 > > Anthony Liguori <aligu...@us.ibm.com> wrote: > > > > > >> We currently model as json bool as an int. This works fine on the server > >> side > >> but it means we cannot send back proper bools to the client. Introducing a > >> proper QBool type fixes that. > >> > > > > As we talked earlier today, I think it would be simpler to have QTrue, > > QFalse and QNull as static objects. > > > > We could define that static objects get reference counting disabled, I > > don't > > see issues in doing that and we get a very simple model. > > > > The big patch bellow does it, only compiled tested though. > > > > If you don't agree with this model, we'll have to allocate QNull objects. > > Actually I would suggest a destroy() method which always resets the > > refcount to 1, but then it will have the concurrency problems on threaded > > applications you've mentioned. > > > > A lot of object systems have dealt with this in various ways. The > trouble with reference counting is usually thread safety. CLR goes to > great lengths to make their objects reference counting thread safe and > it comes at a cost. Python doesn't do anything explicit and it's one of > the reasons that they're stuck with a big lock. > > Since I'd like to expose QObject to client libraries, having a single > static instance would be pretty unfortunate as it would imply a weird > locking semantics. Disabling reference counts for QNull/QBool seems > unfortunate because it suggests that different semantics for certain > objects. > > I think this is a premature optimization. I don't think we need to try > and save the memory here. You can add QNull in your series then.
