On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick 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.
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.
Part point of this exercise is to make it easier to refactor code later. Doing things that make it easier to create hidden, latent bugs is *not* helpful! :)
-------------------------------------------------------
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
