concepts and interfaces

[Martin Hinsch]

James Dennett Wrote:

> janderson wrote:
> > janderson wrote:
> >> Martin Hinsch wrote:
> >>> Inspired by this video (linked by an earlier post, and very
> >>> interesting; I really hope that D will get something similar)
> >>>
> >>> http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
> >>>
> >>> I started to think about the relation of concepts and interfaces.
> >>> In a way both serve very similar purposes, namely supporting
> >>> polymorphism. The major difference is of course that one is used at
> >>> compile time and the other one at run-time. Still, in the end both
> >>> are just a way to describe the constraints which have to be fulfilled
> >>> by a type in order to be usable in a specific generic way.
> >>> Interestingly the syntactic differences are nevertheless
> >>> considerable. My main point in this post is that this is mainly for
> >>> historical reasons and that it might be beneficial to think about
> >>> making interfaces and concepts more similar to each other.
> >>>
> >>> Some more specific thoughts:
> >>>
> >>> - 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).
> >>>
> >>> - 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.
> >>>
> >>> - 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.
> >>>
> >>> Just some food for thought.
> >>>
> >>> cheers
> >>> Martin Hinsch
> >>
> >> I'm not sure D necessarily needs to support this the same way as C++.
> >> However the C++ developers of concepts are very smart people and have
> >> obviously put a lot of thought into this.  We should consider all
> >> options.
> >>
> >> It would be nice when C++0x comes out we could say, D's had all these
> >> features for years.  If your going to switch, why not switch to D.
> >>
> >> -Joel
> > 
> > 
> > Just a thought, could concepts possibly be jammed into contracts?
> > 
> > void Foo(T)(T t)
> > in
> > {
> >     static assert(IsIterator!(T));
> > }
> > body
> > {
> > 
> > }
> 
> Not nicely, as concepts are able to affect things
> like overload resolution; what's wanted if Foo
> requires IsIterator(T) is not a compile-time error
> about an assertion failing, but that the function
> simply drop out of the overload set (so that some
> other function might match).  At least, that's
> the C++ way.  Of course D can be Different.
> 
> -- James

Plus, the charme of C++ concepts is that they are completely separate entities with a syntax which is very similar to a class declaration. IMHO that makes it very easy to really think of them as abstract reusable entities which describe a _concept_.