Re: Struct polymorphism?
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
Re: Struct polymorphism?
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
Re: Struct polymorphism?
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.
Re: Struct polymorphism?
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);
Re: Struct polymorphism?
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.
Re: Struct polymorphism?
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
Re: Struct polymorphism?
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.
Struct polymorphism?
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.
