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.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to