From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzdo8-0006Wy-Kn for qemu-devel@nongnu.org; Sun, 18 Oct 2009 18:00:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzdo3-0006WW-BP for qemu-devel@nongnu.org; Sun, 18 Oct 2009 18:00:55 -0400 Received: from [199.232.76.173] (port=57704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzdo3-0006WT-2h for qemu-devel@nongnu.org; Sun, 18 Oct 2009 18:00:51 -0400 Date: Sun, 18 Oct 2009 20:00:38 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module Message-ID: <20091018200038.298655bc@doriath> In-Reply-To: <4ADB430B.6060507@codemonkey.ws> References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> <1255037747-3340-2-git-send-email-lcapitulino@redhat.com> <4AD72B88.2040107@codemonkey.ws> <20091015122622.1f93ea2d@doriath> <20091015163936.GB532@redhat.com> <20091015142837.6c90580a@doriath> <4AD76B3C.3050001@codemonkey.ws> <4AD87424.3010000@redhat.com> <4AD87901.5030705@codemonkey.ws> <4AD8AECE.9000507@redhat.com> <4AD8AFA4.4070203@codemonkey.ws> <4AD8CB31.9080809@redhat.com> <4AD8E7B5.8000509@codemonkey.ws> <4AD910BA.4090607@gnu.org> <4AD922EB.5030501@codemonkey.ws> <4AD995FD.6070202@snarc.org> <20091018120631.0ab44d80@doriath> <4ADB2172.2040501@gnu.org> <4ADB2B13.4090207@codemonkey.ws> <20091018131818.6d8d73ae@doriath> <4ADB337B.7080803@gnu.org> <20091018140535.17eca067@doriath> <4ADB430B.6060507@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Vincent Hanquez , qemu-devel@nongnu.org On Sun, 18 Oct 2009 11:32:11 -0500 Anthony Liguori wrote: > Luiz Capitulino wrote: > > Okay, I just took a quick look at them and am looking at Anthony's > > right now. > > > > Anyway, my brainstorm on this would be to have to_string() and have > > default methods on all types to return a simple string representation. > > > > What's the value of integrating into the objects verses having a > separate function that can apply it to the objects? Right now it doesn't have any real value, besides being a different style which seems to fit well with the QObject design. In the future it might be needed though, common code might want to change certain methods' behavior before passing QObjects down a call stack.