> > On Mon, May 23, 2016 at 05:57:52AM -0400, Frediano Ziglio wrote: > > You didn't understand the problem, this is not enough > > as a refactory of this would require a complete code scan > > as currently is (was?) needed, you have to check for every > > cast. > > You did not explicitly state the problem either ;) I'm guessing that > you want to get a compile-time error in every places where there is a > cast from child class to base class (or the opposite)? > > Personnally I'd consider that once you have one class inheriting from > another, then the parent instance has to be the first field in the child > instance struct, and that if you change that, you should expect quite > some pain (ie need to grep for both type names and check each use). > Since I don't consider changing the class hierarchy to be something > we'll do often, especially in the PipeItem case, this is why I'd just go > with casts and at most this static check near the struct definition. > > Christophe > I think problem is more complicated than this. First. A distinction must be done! GObject classes and not GObject. GObject classes were introduced recently. The hierarchy is good, the fact that GObject is the first field is the parent so the casts are fine. I'm not against these and if you look at the patch I didn't change any of these. Other part. You can find code where the parent is NOT the first field (for different reasons), I did some improvements on this. You can also find places were a class is "inherited" just to reuse some feature, so it's really likely when this class will evolve you can have this field replaced by something else or moved (for instance if you have a more strong parent class). Unfortunately this is the way RedPipeItem and other classes are used. For these cases I much more prefer having to add a possible ".base" wherever will be needed than spending hours of debugging (as I did) trying to figure it out which part of code is writing the field "xxxx" without using the "xxxx" name or even the "Yyyy" structure which contains "xxxx". Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel