www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Interfaces with structs...?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  Something that was coming to mind a while back was that classes 
can include interfaces while structs cannot. I can understand 
easily why this wouldn't work being much lower level compared to 
how classes are (And the vast varying of parameters and return 
types).

  But could the notation be allowed for more documentation 
purposes? Or more for contract debugging? Course it would only 
work with templates since that's how the constraints work...

  Example:

  struct something : isForwardRange
  {}

  I would think the equivalent would be a simple conversion to a 
unittest code:

  struct something{}

  unittest {
   assert(isForwardRange(something), "Fails to satisfy 
'isForwardRange' template!");
  }

  Now this is just a thrown out thought/idea, but curiously I 
don't think it would change much semantically... would it?
Jul 05 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I just had a wild idea... struct A : static Interface {}

the static means it checks for the functions but doesn't
do any runtime polymorphism.
Jul 05 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 05-Jul-12 22:23, Adam D. Ruppe wrote:
 I just had a wild idea... struct A : static Interface {}

 the static means it checks for the functions but doesn't
 do any runtime polymorphism.

Hm... sounds not bad. And it adds another way to reuse static, thus Walter must love the idea *LOL* -- Dmitry Olshansky
Jul 05 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, July 05, 2012 20:17:24 Era Scarecrow wrote:
   Something that was coming to mind a while back was that classes
 can include interfaces while structs cannot. I can understand
 easily why this wouldn't work being much lower level compared to
 how classes are (And the vast varying of parameters and return
 types).
 
   But could the notation be allowed for more documentation
 purposes? Or more for contract debugging? Course it would only
 work with templates since that's how the constraints work...
 
   Example:
 
   struct something : isForwardRange
   {}
 
   I would think the equivalent would be a simple conversion to a
 unittest code:
 
   struct something{}
 
   unittest {
    assert(isForwardRange(something), "Fails to satisfy
 'isForwardRange' template!");
   }
 
   Now this is just a thrown out thought/idea, but curiously I
 don't think it would change much semantically... would it?

Aside from the problem that it looks like inheritance when it's not, declaring an interface for a struct would actually be too restrictive in many cases. Look at what isForwardRange looks like template isForwardRange(R) { enum bool isForwardRange = isInputRange!R && is(typeof( (inout int _dummy=0) { R r1 = void; R r2 = r1.save; // can call "save" against a range object })); } If it were defined with an interface, how would you deal with the fact that none of the types are fixed? Templatize the interface? That might work, but the more complicated the requirements for the template constaint, the harder that will be, and I'm not sure that it can even always work to do that. What we have may take some getting used to, but it works really well. - Jonathan M Davis
Jul 05 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 5 July 2012 at 18:30:51 UTC, Jonathan M Davis wrote:
 Aside from the problem that it looks like inheritance when it's 
 not, declaring an interface for a struct would actually be too 
 restrictive in many cases.

<snip>
 If it were defined with an interface, how would you deal with 
 the fact that none of the types are fixed? Templatize the 
 interface? That might work, but the more complicated the 
 requirements for the template constaint, the harder that will 
 be, and I'm not sure that it can even always work to do that. 
 What we have may take some getting used to, but it works really 
 well.

Mmm.. maybe 'interface' is the wrong word. More like 'qualifies to use the following template(s)'... I was thinking it more like an early static check ensuring the struct hits certain requirements, outside of the early checks it is completely ignored and structs work as normal. (Like the unittest example I gave) Having it use an actual interface wouldn't work well due to how diverse the various templates functions that call on the structs work.
Jul 05 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 5 July 2012 at 18:36:06 UTC, Dmitry Olshansky wrote:
 And it adds another way to reuse static, thus Walter must love 
 the idea *LOL*

We can never have too much static! (and it actually does fit here...)
Jul 05 2012