www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Struct polymorphism?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  What are the possibilities of struct polymorphism? What would be 
the issues with it? What if we wanted to use it in a limited 
sense?

  Currently I'm experimenting with it since classes are too bulky 
for what I need, yet I really need some type of behavior/dynamic 
polymorphism. So far I have a working model. It takes the 
following limitations:

   1) struct size can't size (no loss of data).
   2) every structure aside from the original needs a copy of the 
original (and only that)
   3) original structure needs an enum specifying behavior mode
   4) Template instantiation cannot be used (although automatic 
type deduction works).


  Using these and limiting it seems like it would sort of bring 
back C++'s design of classes, only better, simpler, and more 
powerful. It won't have an actual full virtual table as 
everything is known statically ahead of time, with only minor 
checks by opDispatch to determine which function set to run.

  Issues:
   1) the base/original struct always calls it's own functions. A 
little work and I can probably remove that limitation, but the 
original struct would end up being only storage with no behavior 
at all.
   2) Template instantiation. This is a limitation in opDispatch() 
where calling through it. As shows below. Maybe I'm just using 
opDispatch wrong.

//signatures lacking structs
auto ref opDispatch(string fun, Args ...)(auto ref Args args) 
 property;
I templateType2(string val1, I)(I val);


//call
ps.templateType2!"Extra Extra!"(50);

Error: ps.opDispatch!("templateType2") isn't a template


  Beyond this it seems to have some potential. Thoughts? Ideas?
Oct 07 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 7 October 2012 at 10:04:57 UTC, Era Scarecrow wrote:

   1) struct size can't size (no loss of data).


  1) struct sizes and structures can't change (no loss of data)
Oct 07 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
   Error: function expected before (), not 
'this.polyBase.opDispatch!("orig")'

   I think this is a compiler bug. It complains about calling
opDispatch, however it doesn't complain if you explicitly call
'this'. Should adding 'this' be required? I am using the
-property switch so it's a little more strict, but that doesn't
seem to change the results. I can't just start adding 'this' to
all my function as outside normal functions/variables won't ever
be seen.

struct S {
   Something polyBase;
   alias polyBase this;  //opDispatch

   string callsOrig() {
     return orig;        //works but misleading
     return orig();      //breaks
     return orig(1);     //breaks too
     return this.orig(); //works
   }
}

struct Something {
   auto ref opDispatch(string fun, Args ...)(auto ref Args args)
 property;
}

   My experiments concentrating on this part rather than with
arguments, those will come later when this works.
Oct 08 2012
prev sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 7 October 2012 at 10:04:57 UTC, Era Scarecrow wrote:

 What are the possibilities of struct polymorphism? What would 
 be the issues with it? What if we wanted to use it in a limited 
 sense?

 Currently I'm experimenting with it since classes are too bulky 
 for what I need, yet I really need some type of 
 behavior/dynamic polymorphism. So far I have a working model. 
 It takes the following limitations:


  A question of efficiency comes up. If at compile-time we can 
confirm only a couple branches/possibilities, then only those are 
considered during run-time. During optimization is that code just 
inlined to where it is called rather than the jump to opDispatch? 
Seems like it should if it's small enough, especially if there's 
only 1 possibility.


  Now I guess a question out there for you all. Who would be 
interested in an implementation and how would you use it? Does it 
seem like a good idea? How many levels would you want to use? 
One? Several levels allowing class-like inheritance?
Oct 08 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 9 October 2012 at 03:41:42 UTC, Era Scarecrow wrote:

 Now I guess a question out there for you all. Who would be 
 interested in an implementation and how would you use it? Does 
 it seem like a good idea? How many levels would you want to 
 use? One? Several levels allowing class-like inheritance?



  Nothing yet it seems. Hmmm...

  Well I've thrown together a working version (in the last 4 
days?) that needs more testing and documentation; But is a proof 
of concept, probably good enough for my other project. 
Incorporates a minimal encryption library for testing and 
demonstration. This makes heavy use of mixins.

  Thoughts and feedback are welcome.

  https://github.com/rtcvb32/Side-Projects
Oct 11 2012