On 03/26/2012 02:44 PM, Jan Kiszka wrote:
On 2012-03-26 21:39, Anthony Liguori wrote:
On 03/26/2012 02:37 PM, Jan Kiszka wrote:
On 2012-03-26 21:35, Anthony Liguori wrote:
Since this is an easily refactorable thing to look at later, I think
we should
start with extracting the types.
My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.
I'm not really worried about it. It's so easier to refactor this
later. Why rush it now?
You rush changing the current layout, not me. :)
No, I'm trying to do incremental changes without boiling the ocean in
the process.
I think we all are in violent agreement about where we want to end up
(as opaque types as possible). I don't want to hold back additional
refactoring on doing this right (and it's not just a matter of
malloc/free).
Either I'm missing it in the code shuffling, or it's not part of this
series: Can you point out where more that a forward reference and
malloc/free is needed?
QOM is built around the concept that the type size is know (as is GObject).
type_initialize() assumes that the pointer passed is an adequate size.
You would either need to move to a model where the memory was completely owned
by QOM (which would mean folding type_new into type_initialize) or have a way to
query instance size for a given type.
This would also mean that reference counting should be revisited although with
how dereferencing a parent affects the child.
It's not rocket science, but it's also something that needs to be done
carefully.
Regards,
Anthony Liguori
Jan
