>>> +#define HERBIVORE(obj) \>>> + INTERFACE_CHECK(Herbivore, (obj), TYPE_HERBIVORE)>>> +>>> +typedef struct Herbivore>>> +{>>> + Object obj;>>> +} Herbivore;>>>>>> All this is doing is saying Herbivores are Objects right? A user cant>> add anything to this struct given that interfaces are stateless so>> could this be simplified to>>>> typedef Object Herbivore;>>> This is admittedly a little wierd...>> Interfaces don't exist as Objects in QOM.
Not in the sense that they used too, but all objects that implement an
interface are still OBJECTs just through the inheritance path of their
concrete class, which is the point of this struct yes?
They are just classes. But it's
> very handy to be able to have a Herbivore type that you can cast objects to.>
Yes I agree in full, but the typedef definition is functionally
equivalent to what you have there, and removes the temptation to add
fields to the object type. Having a skeletal struct there gives the
illusion to readers that interface objects are in someway extensible.
> I probably need to respin this though. INTERFACE_CHECK() asserts that an> object implements the interface class and then just returns the obj and> casts it to the dummy Interface object type.>> A better approach would be to just teach object_dynamic_cast to do this for> anythign that's an interface type. That would fix the link problem you> pointed out too. I'll spin a v2.
Please see my patch, I have a little 3 patch series up on the list.
that starts with your v1, does the axi-stream stuff then fixes that
bug.
Regards,
Peter
>> Regards,>> Anthony Liguori>>>>> ?>>>>> +>>> +typedef struct HerbivoreClass>>> +{>>> + InterfaceClass parent;>>> +>>> + void (*feed_greens)(Herbivore *obj);

Am 18.06.2012 15:46, schrieb Peter Crosthwaite:
>>>> +#define HERBIVORE(obj) \>>>> + INTERFACE_CHECK(Herbivore, (obj), TYPE_HERBIVORE)>>>> +>>>> +typedef struct Herbivore>>>> +{>>>> + Object obj;>>>> +} Herbivore;>>>>>>>>> All this is doing is saying Herbivores are Objects right? A user cant>>> add anything to this struct given that interfaces are stateless so>>> could this be simplified to>>>>>> typedef Object Herbivore;>>>>>> This is admittedly a little wierd...>>>> Interfaces don't exist as Objects in QOM.> > Not in the sense that they used too, but all objects that implement an> interface are still OBJECTs just through the inheritance path of their> concrete class, which is the point of this struct yes?> > They are just classes. But it's>> very handy to be able to have a Herbivore type that you can cast objects to.>>> > Yes I agree in full, but the typedef definition is functionally> equivalent to what you have there, and removes the temptation to add> fields to the object type. Having a skeletal struct there gives the> illusion to readers that interface objects are in someway extensible.
Why have a typedef at all then? You can just use Object directly. If
that ever changes it leads to all kinds of problems (well, necessary
adjustments), as seen in the pci_host series.
Andreas

On 06/18/2012 08:51 AM, Andreas Färber wrote:
> Am 18.06.2012 15:46, schrieb Peter Crosthwaite:>>>>> +#define HERBIVORE(obj) \>>>>> + INTERFACE_CHECK(Herbivore, (obj), TYPE_HERBIVORE)>>>>> +>>>>> +typedef struct Herbivore>>>>> +{>>>>> + Object obj;>>>>> +} Herbivore;>>>>>>>>>>>> All this is doing is saying Herbivores are Objects right? A user cant>>>> add anything to this struct given that interfaces are stateless so>>>> could this be simplified to>>>>>>>> typedef Object Herbivore;>>>>>>>>> This is admittedly a little wierd...>>>>>> Interfaces don't exist as Objects in QOM.>>>> Not in the sense that they used too, but all objects that implement an>> interface are still OBJECTs just through the inheritance path of their>> concrete class, which is the point of this struct yes?
Yes, they are objects, which is why the struct just contains Object. It's
basically just a type-safe wrapper for Object. Nothing more than that.
>>>> They are just classes. But it's>>> very handy to be able to have a Herbivore type that you can cast objects to.>>>>>>> Yes I agree in full, but the typedef definition is functionally>> equivalent to what you have there, and removes the temptation to add>> fields to the object type. Having a skeletal struct there gives the>> illusion to readers that interface objects are in someway extensible.
typedef struct Object Herbivore;
is a weak alias. IOW, it's not an error to pass Object * instead of Herbivore
*. Worse yet, passing Carnivore * also is not an error.
The struct definition provides a strict alias. We could wrap it in a macro to
avoid confusing the reader I guess.
> Why have a typedef at all then? You can just use Object directly. If> that ever changes it leads to all kinds of problems (well, necessary> adjustments), as seen in the pci_host series.
Type safety.
Regards,
Anthony Liguori
>> Andreas>