As I'm looking over the bottlenecks in speed and useage I'm finding that classes are much too bulky for the subrecords I'll be needing. This poses a problem. The average subrecord is something like 64bytes, and the data structure for the class by itself is over 300 (last I saw somewhere), plus the virtual table and declared variables. Keep in mind I'll likely be working with well over 400,000 entries, so memory and speed become an issue the larger this scales up with classes. (My tests on a 80Mb input file became over 500Mb and took a while to load)

 As I'm thinking about this, I wonder if I can trim that to a minimum. Let's consider this (posted on another forum as notes mostly):

[code]
enum Type { normal, FRMR, LAND }
struct SubRecord {
  Type polyMorph;

  //other data
  string generateID();
}

struct FRMR {
  SubRecord root;
  alias root this; //subtyping

  //no new data is added, only methods/behavior

  string generateID() { //overrides original subrecord's
         //generate string
         //or if i use root.generateID(), i get the original
         return "";
  }
}
struct LAND {
  SubRecord root;
  alias root this; //subtyping
}

 union {
   SubRecord subrecord;
   FRMR frmr;
   LAND land;
 }

 subrecord.generateID(); //legal
 if (subrecord.polymorph == Type.FRMR)
   frmr.generateID(); //get FRMR behavior at no cost!
 if (subrecord.polymorph == Type.LAND)
   frmr.generateID(); //get FRMR behavior at no cost!
[/code]

 Now as long as you're willing to check for individual subrecords (and there's only 5 or so so it isn't a huge issue), but growth to polymorphism quickly could escalate it to be large and annoying. To make it truly poly-morphic then perhaps the following.

[code]
 struct SubRecord {
  Type polymorph;

  string generateID() {
    if (polymorph)
          return polymorphed!(polymorph, "generateID");

    string ID;
    //generate normal SubRecord ID
    return ID;
  }

  auto polymorphed(poly, string call, Vars[] ...)() {
    string typeName; //convert somewhere in here.

    mixin("return (cast(" ~ typeName ~ ") this)." ~ call ~ "(" ~ Vars ~ ");");
  }
 }
[/code]

 now I'm sure the template calling is likely wrong (as poly's value is runtime), but re-arranging it so it separates out the enums at runtime and then calls static versions of them you can get the wanted effect.

 Now assuming you get the code above working then...

[code]
  SubRecord sr, sr2;

  sr2.Type = Type.FRMR;

  sr.generateID();
  sr2.generateID(); //FRMR version! Minimal cost!
[/code]


 Thoughts? Ideas? Does this seem feasible? Potential issues down the road? I'll be experimenting to see if I can indeed do this. If someone is already done or failed at this I wouldn't mind reading their attempts on it.

 Perhaps someone can help explain this mystery. I've got a working system, except when it's coming to an unknown function inside my structs.

 Perhaps to note opDispatch is added via a mixin template, not sure if that makes a difference.

Error: function expected before (), not 'this.polyBase.opDispatch!("orig")'

  struct Base {
    PolyMorph polyBase;
    alias polyBase this;

    string callsOrig() {
      return orig(); //dies here
    }
  }

  //opDispatch signature
  auto ref opDispatch(string fun, Args ...)(auto ref Args args);

On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote:
> 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.

On 10/08/2012 03:19 PM, Era Scarecrow wrote:
> On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote:
>> 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 don't know all of the design decisions behind opDispatch, but I would be happier to have to type "this." when inside the struct. Otherwise, any struct that defined opDispatch would miss out on compiler's static name checking.

What if orig() has actually been a mistyped free-standing function name? Being forced to type this.orig() makes it explicit. And to me, this seems even better:

    return polyBase.orig(1);

> I can't just
> start adding 'this' to all my function as outside normal
> functions/variables won't ever be seen.

Sorry, I can't understand the problem that you describe in that sentence.

Ali

On Monday, 8 October 2012 at 22:57:04 UTC, Ali Çehreli wrote:
> I don't know all of the design decisions behind opDispatch, but I would be happier to have to type "this." when inside the struct. Otherwise, any struct that defined opDispatch would miss out on compiler's static name checking.
>
> What if orig() has actually been a mistyped free-standing function name? Being forced to type this.orig() makes it explicit. And to me, this seems even better:
>
>     return polyBase.orig(1);

 Yes likely this is what will happen.. Just seems like it isn't needed.

>> I can't just start adding 'this' to all my function as outside normal functions/variables won't ever be seen.
>
> Sorry, I can't understand the problem that you describe in that sentence.

 Hmmm added a this.writeln() and it worked fine without calling opDispatch. How odd. Still seems like a compiler bug to me.

 The idea behind that i'm experimenting with is in reality the struct contained two functions. So..

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

  string orig() {
    return "some string";
  }

  string callsOrig() {
    return orig();
  }
}

 With that everything is happy. Now if I rename orig to Poly_orig, then callsOrig complains and the issue comes up. The polyBase will check among the rules it has and adds Poly_ to the functions while it's checking them (among other ones), before finally calling S.Poly_orig() with all it's arguments.

So it will look something like this.

struct Data {
  string msg;
}
struct Something {
  Data data;  //shared data
  auto ref opDispatch(string op, Args ...)(auto ref Args args) {
    static if (op == "orig") {
      return (cast(S) data).Poly_orig();
    } else {
      static assert(0, op ~ " - Not found"); //205
    }
  }
}

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

  //string orig() {    //statically assigned
  string Poly_orig() { //opDispatch calls now
    return "some string";
  }

  string callsOrig() {
    return orig(); //220
    return this.orig();
    return polyBase.orig();
  }

  string oddball() {
    //asserts can't find blarg or Poly_blarg in opDispatch
    return blarg();  //227
    return this.blarg(); //228
  }
}

test.d(220): Error: function expected before (), not 'this.polyBase.opDispatch!("orig")'
test.d(227): Error: function expected before (), not 'this.polyBase.opDispatch!("blarg")'
test.d(205): Error: static assert  "blarg - Not found"
test.d(228):        instantiated from here: opDispatch!("blarg",)

  I'd rather have where once I get my code debugged for a struct that I don't have to suddenly add this. or polyBase to all my functions after I rename the functions to Poly_. If it's a necessary evil than I'll accept it.

On 2012-10-09 00:19, Era Scarecrow wrote:

>    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.

As far as I understand it, opDispatch needs a receiver, i.e. this.foo() or obj.foo(). I asked the same question a while ago and got that answer, it's by design.

-- 
/Jacob Carlborg

On Tuesday, 9 October 2012 at 06:53:54 UTC, Jacob Carlborg wrote:
> As far as I understand it, opDispatch needs a receiver, I.e. this.foo() or obj.foo(). I asked the same question a while ago and got that answer, it's by design.

 I've also tried adding a opDispatch in the same struct and the error still comes up. Guess it doesn't qualify opDispatch as known at compile-time unless you explicitly say so.

 Mmm.. I'm not satisfied with that, but it's a lesser evil we can live with.

It's having possibilities,I mean polymorphism for struct,and
without a enum declaring thus it can be more scalable if you
should use virtual call in a delegate class,cause it's just what
virtual call is designed for.Since you record the Type all the
time,you get rid of virtual call but lose scalability.I'm
interesting in struct polymorphism because I can choose no
virtual call when no runtime polymorphism is needed but not when
I need