concepts and interfaces

Martin Hinsch m.hinsch.spam at rug.nl
Sun Apr 8 12:43:28 PDT 2007


Reiner Pope Wrote:

> I would imagine that complete compile-time introspection information 
> would make a lot of this much easier in D -- a lot of it could be 
> implemented in the libraries.
> 
> > - why does conformance to an interface have to be specified explicitly (as in class C implements interface I)? Why not do post-hoc checking as with concepts/templates?
> > Using an object via an interface implies two things - the compiler has to check whether the objects class actually implements all methods required by the interface and the object reference has to be manipulated in such a way that when using it when assigned to an interface reference the right method calls are done. If we assume that all casts from an object to an interface reference are visible at compile time both of these could be done *at the point of the cast* (equivalent to the way type checking is done for template instantiation).
> I agree. This idea (often called structural typing, as opposed to 

Cool, there's even a name for this! I considered myself quite clever to come up with the idea ;-). (so much for amateur-level computer science... ;-)

> nominative typing) is often much more flexible. There can be a pitfall, 
> though, in that you then have less distinction between types. For instance
> 
>     typedef FirstInterface SecondInterface;
> 
> would then be pointless, since they are (implicitly?) convertible to 
> each other.
> 

Hmm, I don't see why that would be a problem. Isn't that the whole point? You could get rid of the clumsy parallel inheritance hierarchy and even apply interfaces to classes retroactively. BTW, if I'm not mistaken, gcc had a c++ extension at some point that worked similar...
On second thought though, you of course lose the ability to "tag" classes by making them derive from a specific interface...

> If you needed to explicitly specify the conversion, that problem might 
> go away. And with compile-time introspection, you could implement it 
> just in the compiler, without any compiler assistance:
> 
>     T convert(T, U)(U value)
>     {
>         static assert((is(U == interface) || is(U == class)) && is(T == 
> interface));
>         // Check that U conforms to T
>         // Now grab pointers to each of U's relevant functions from its 
> vtbl, and generate a new vtbl and object for T
>     }
> 
> > - interface_maps
> > With implicit implementation of interfaces the concept_map idea might come in handy for interfaces as well, allowing to do some adjustments to make a class conforming to an interface.
> I agree. I think, with reflection, this could be implemented in userland 
> like above. Perhaps also relevant is C#'s explicit interface 
> implementation, which (IIRC) allows you to implement the interface under 
> different names (but only within the class; not in retrospect).
> 
> > - why not make concepts obligatory?
> > One of the beneficial aspects of using interfaces is in my opinion that it forces you to be specific about which properties you expect from the plugged in types. This is something which is missing from generic programming and which is supposed to be improved by introducing concepts. C++ of course has to stay backwards-compatible therefore concepts will be completely optional.
> > In D OTOH concepts could actually be made obligatory forcing the programmer to be explicit about the properties of the types which can be plugged into a template/generic class.
> Ideally, yes.
> 
> Just of the top of my head, though, there may be practical concerns 
> which prevent this.  You can do complicated things with templates in D, 
> so you can have complicated requirements. Specifying such constraints 
> could perhaps be difficult, lengthy, or impossible, depending on the 
> syntax of your constraint specifications. Sometimes it's just not worth 
> it, and making it compulsory could just make it irritating. Since it's 
> effectively type-checking for your template parameters, I guess we could 
> expect the same annoyances that we get with static type checking. I 

Could you give an example?

> think you can conclude from this that you would almost definitely need 
> some kind of back door, like a cast.
> 

The easiest solution would of course be to include a built in "any"-concept which forwards type checking to instantiation time.

> C# makes the specifications compulsory with where clauses -- most of the 
> time, this is a good feature; I would perhaps even say all the time 
> except for it's limitation in specification, especially of constructors. 
> Of course, you can't do any where near as much with C# generics as with 
> D templates.
> 
> C++'s concepts seem to be quite expressive. Perhaps they would be 
> expressive enough to make compulsory. Perhaps backwards compatibility 
> with pre-concepts code is the reason they aren't compulsory.
> 

They actually even say so in the talk.




More information about the Digitalmars-d mailing list