<div>On 5/26/05, Bill Spitzak <<a href="mailto:spitzak@d2.com">spitzak@d2.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> As soon as your wrapper requires virtual functions, you will start making code that only takes your wrapper, rather than a cairo_t, as an argument. This is VERY bad. The big deal with Cairo is not antialiased graphics. The big deal is that there is a hope that portable drawing functions will be possible, where the only argument is a cairo_t, and they will work in Qt widgets and GTK widgets and GTK canvas objects and in a raw XCB or Xlib program, or in a Windows .net program. If you put virtual functions around this you will completely kill this idea and that would be very bad. </blockquote></div> I'm not suggesting something like Gtk# should return an object derived from the Graphics object, or the Cairo bindings themselves. The reason the object would have virtual functions is so an application can override them itself. For instance, overriding the Save and Restore calls would allow an application to preserve extra state information. This can of course be achieved without virtual functions, and just calling the functions something else - but having virtual functions adds to the flexibility and clarity of the api. Neither is this a bug in Cairo since it cannot be aware of what the programmer wants to achieve in overriding these calls.