contravariant argument types: wanna?

[Jeremie Pelletier]

Steven Schveighoffer wrote:
> On Tue, 22 Sep 2009 22:02:59 -0400, Jeremie Pelletier 
> <jeremiep at gmail.com> wrote:
> 
> 
>> Yeah most of my display interfaces would make use of covariant 
>> arguments, I use main abstract factory for the entire package, and the 
>> objects it creates contain factory methods themselves. I plan to have 
>> implementations for all of win32, gdk, x11, quartz, cairo, pango, d2d, 
>> dwrite, gl, gl3 and finally d3d7 up to d3d11. Most of the client code 
>> will therefore see only the interfaces in order to maintain 
>> portability, and to allow different implementations to live in the 
>> same executable (for example win32/gl/cairo/pango for up to vista or 
>> win32/d3d/d2d/dwrite if on win7 and up).
>>
>> Here is a watered down version of a few interfaces I use, which are 
>> used by client code:
>>
>> interface IDrawable {}
>> interface IWindow : IDrawable {} // onscreen drawable
>> interface ISurface : IDrawable {} // offscreen drawable
>> interface IDisplayContext {} // base of 2d-3d contextes
>> interface IRenderContext {} // 3d context
>> interface IWindowRenderContext {} // specialized onscreen 3d context
>> interface IRenderer {
>>     IWindowRenderContext CreateRenderContext(IWindow);
>>     ISurfaceRenderContext CreateRenderContext(ISurface);
>> }
>>
>> And some of their current implementation, which are all used within 
>> the package:
>>
>> abstract class Win32Drawable : IDrawable {}
>> final class Win32Window : Win32Drawable, IWindow {}
>> final class Win32Surface : Win32Drawable, IWindow {}
>>
>> final class GLRenderer : IRenderer {
>>     GLWindowRenderContext CreateRenderContext(IWindow window) {
>>         if(auto win32Window = cast(Win32Window)window)
>>             return new GLWindowRenderContext(win32Window);
>>         else throw new Error();
>>     }
>>     GLSurfaceRenderContext CreateRenderContext(ISurface surface) {
>>         if(auto win32Surface = cast(Win32Surface)surface)
>>             return new GLSurfaceRenderContext(win32Surface);
>>         else throw new Error();
>>     }
>> }
>>
>> abstract class GLRenderContext : IRenderContext {}
>> final class GLWindowRenderContext : GLRenderContext, 
>> IWindowRenderContext {
>>     this(Win32Window) {}
>> }
>> final class GLSurfaceRenderContext : GLRenderContext, 
>> ISurfaceRenderContext {
>>     this(Win32Surface) {}
>> }
>>
>> I have over a hundred of such methods doing dynamic casts across all 
>> the different implementations like these twos in this package alone, a 
>> display interface is quite a large beast.
>>
>> Of course if you can suggest a better way of doing methods expecting a 
>> specific implementation of an object, while still allowing client code 
>> to call them with the interface pointer, I'd be glad to implement it :)
>>
>> Jeremie
> 
> There are some possible solutions.  First, it looks like you are using 
> interfaces to abstract the platform, which seems more appropriate for 
> version statements.  I once wrote an OS abstraction library in C++, and 
> in my fanatic attempt to avoid using the preprocessor for anything, I 
> made everything interfaces (pure abstract classes).  I think with D, the 
> version statements are a much better solution, and will reduce overhead 
> quite a bit.
> 
> Second, Your IRenderer is the one responsible for creating a render 
> context, but it depends on being "hooked up" with the appropriate 
> IWindow or ISurface object.  However, the IRenderer implementation's 
> methods are pretty much static (granted they might be trimmed down).  
> Why not move them into the IWindow and ISurface interfaces?
> 
> interface IWindow : IDrawable {
>   IWindowRenderContext CreateRenderContext();
> }
> 
> interface ISurface : IDrawable {
>   ISurfaceRenderContext CreateRenderContext();
> }
> 
> If you need an instance of IRenderer for some other reason not shown, 
> then consider using a hidden singleton of the correct implementation.
> 
> -Steve

Because there will be multiple implementations living in the same 
executable. We all know how microsoft likes to force new technology to 
new windows versions. I want support for Direct2D, DirectWrite, and all 
versions of Direct3D. Which requires different implementations for 7, 
vista, and xp. Then some people might have better performance with GL, 
for graphic adapter vendor and driver issues, so I'm throwing such an 
implementation in the mix. On unix you have a choice of different 
windowing toolkits, be it Gnome, Qt, Xfce or directly using X11 but 
losing specific features offered by the toolkits.

As for merging IRenderer with the drawables, this wouldn't fit my 
design. I use what I call render contexts and paint contexts for 3d and 
2d drawing respectively, which are both built upon a common set of 
display interfaces to get most of their shared concepts unified and 
compatible with one another. I also have font layering and rendering 
interfaces usable by the two. And given that many different render and 
paint implementations can be used from the same drawable targets, it 
wouldn't make sense.

My first design was using version statements but it was far from 
flexible enough for my needs. The overhead is mostly needed to allocate 
the interfaces, not to use them so the speed isn't affected.

Then you get my I/O interface which roots at simple input/output 
streams, then seekable streams, binary streams, file streams, async 
streams, pipes, etc. And get different implementations for local 
filesystem I/O, sockets, specialized file format abstractions, and 
whatnot. So for example a method expecting an IInputStream does not care 
what is implementing it, so long as it has a read method implemented, be 
it reading data from a file, from a network connection, from a packed 
file within an archive. These implementations still need covariant 
parameters within themselves for a few things.

Jeremie