From: Philip B. <ph...@bo...> - 2003-03-05 22:06:23
|
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > > > Also, rather than containing the struct, you could do what is done already > > in the drm level, with drm_map_t vs drm_local_map_t (and all over the X > > server code), and just extend the struct, rather than encapsulating it. So > > [quick-n-dirty illustration for discussion purposes] > > > > struct dritexture{ > > int baseval; > > }; > > struct radeontexture { > > int baseval; > > int radeonextraval; > > }; > > So what happens when you want to refactor and move data out of > radeontexture and into dritexture? Then the functions that operate on > dritexture will possibly break. how so? If you have a non-radeon card driver using dritexture, it will ignore the extra field added. Or, it will keep using the same "base" functions, which, if you done the "refactoring' right, will be a transparent change. If you have a radeon card driver routine that previously accessed the extra field.. it can STILL access the extra field. So what will break? > > Also, since functions are not part of "the object", I dont see where > > "overriding functions" comes into play. If you dont want to use a "base" > > function, you just call a radeon-specific one? > > That's exactly the problem! If you change from using the "base" > function to using a derrived function, you have to touch the code in > every single place that used the base function. If you miss one, you > have a bug...a bug that may go a long time unnoticed. Are you honestly making the argument, "Hunting down places that called RadeonTextureTwiddle, and renaming them to DriTextureTwiddle, is a difficult operation that can lead to bugs" ?? It should be a straightforward excercise to migrate a sub-object function, into a base-object function, as describe above. If it isnt, there are two possibilities: a) It doesnt BELONG as a base object function. case closed. b) the writer of the sub-object function, did a poor job designing/writing the sub-object function. In which case, the author needs to be whipped^H^H^Hreeducated, and made to fix the design. Only after that is done, should it then be migrated up into the base object. in this model, it should not be a bug magnet any more than the corresponding operation of migrating from a C++ derived class to a parent class. |