[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [Qemu-devel] [RFC for-2.8] machine: Convert abstract t
From: |
Halil Pasic |
Subject: |
Re: [Qemu-stable] [Qemu-devel] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names |
Date: |
Mon, 12 Dec 2016 18:13:50 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
On 12/12/2016 01:25 PM, Cornelia Huck wrote:
>> + if (oc && object_class_is_abstract(oc)) {
>> + /* temporary hack to make sure we will never override
~~~~~~~~~~~~~~~~~~~~~~
I would say this is not enough to provide that guarantee. Inheriting
from non-abstract, or something like I described below, would still
get us in trouble. Or am I wrong?
How about s/we will never/we do not/?
>> + * globals set explicitly on -global: if an abstract class
>> + * is on compat_props, register globals for each of their
>> + * subclasses instead.
I'm not sure if this is clear enough regarding multilevel inheritance.
I would prefer "subtype" or "class derived from it".
>> + */
> I think this should not just be a 'temporary hack'... rather document
> this behaviour for abstract classes?
>
Connie, I have to disagree with you on this. I'm fine with this as a
temporary hack provided it remedies the acute problem, but I would this
becoming state of art.
The reason for this how abstract class is usually understood in OOP:
it's like a normal class except you can not instantiate it. Adding an
extra property rule, and especially such a convoluted one, could result
in a conflict between intuition and reality. And it's not like we have
no plan how to do this cleanly.
Why do I say convoluted:
* Inheriting form abstract and from non-abstract behaves differently.
* Theoretically we have something like non-abstract (C_3) inherits for
abstract (AC_2) inherits from non-abstract (C_1) inherits from abstract
(AC_0), and we set the property P both via AC_0 and AC_2 for an instance
of C1 we would/could end up having the same problem as we have now (via
AC_0 taking precedence over AC_2) -- at least I think so.
I did not test it either, but it looks sane to me. Regardless of the
comments on the comment (if you are going to consider them or not) you
can take my r-b.
Cheers,
Halil
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, (continued)
- Re: [Qemu-stable] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names, Cornelia Huck, 2016/12/12
- Re: [Qemu-stable] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names, Eduardo Habkost, 2016/12/12
- Re: [Qemu-stable] [Qemu-devel] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names,
Halil Pasic <=
- Re: [Qemu-stable] [Qemu-devel] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names, Eduardo Habkost, 2016/12/12
- Re: [Qemu-stable] [Qemu-devel] [RFC for-2.8] machine: Convert abstract typename on compat_props to subclass names, Halil Pasic, 2016/12/12
Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Michael S. Tsirkin, 2016/12/06
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Eduardo Habkost, 2016/12/06
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Michael S. Tsirkin, 2016/12/06
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Eduardo Habkost, 2016/12/06
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Michael S. Tsirkin, 2016/12/06
- Re: [Qemu-stable] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Eduardo Habkost, 2016/12/06
- Re: [Qemu-stable] [Qemu-devel] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Stefan Hajnoczi, 2016/12/06
- Re: [Qemu-stable] [Qemu-devel] [PATCH] virtio: fix HW_COMPAT_2_6 macro for virtio-*-pci drivers, Greg Kurz, 2016/12/07