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.
Regards,
Anthony Liguori