Been a while and out of the loop, I need to get my hands dirty
in the code again (soon). Anyways, let's get to the matter at
hand as I'm thinking about it. I'm working on some code (or will
work on code again) that could use a polymorphic type, but at the
end it will never be shared externally and can never extend
beyond 'Known' types. (and the 'types' are behavior 95% of the
time)
True polymorphism will let me compile a code to work with say
'Object' and you can plug in any code and pass it an object and
it will be happy, or inherit and work with it. These are great as
classes. But I want to throw a wrench in the gears, I want to use
structs.
I know you're asking, Why? Well the data structure I'll be
working with have records in the hundreds of thousands, but most
of the time looking at/sorting them I don't necessarily need to
allocate memory (or really even interact with them beyond
sorting). Most of the time the OO aspect is just behavior and the
data between them never changes (behave this way because you're a
type XXX). It can take a very long time to unpack everything
(when you never needed to unpack in the first place, or allocate
and then de-allocate immediately, probably without recycling).
Alright, structs can't inherit because they don't have an object
pointer to go to their parent structures that they are connected
to. If we eliminate the pointer and the overhead on some of that,
we bring it down to the following:
To be fully polymorphic you need to:
* Be able to tell what type it is (Probably enum identifier)
* Extended types cannot be larger than the base/original (or the
base has to hold extra data in reserve for it's other types).
When can this LSP be applicable?
* When a type can be changed on the fly with no side effects
other than intended (This 'text' struct is now 'left aligned text
object')
* When allocations/pointers aren't needed (why fully build the
object at all?)
* When it won't be extended beyond the current type... (only a
few fixed subtypes)
* When teardown/deallocation/~this() isn't needed (never
allocates? Never deallocates! Just throw it all away! POD's are
perfect!)
* When you have no extra 'data' to append to a class/struct and
only override methods/behavior (Encryption type switch from DES
to BlowFish! Same API/methods, otherwise nothing really changed)
* When you need a half step up from structs but don't need full
classes/objects
Limitations: Hmmm..
* LSP's cannot be a template or mixin (they can call on them)
* Known at compile-time
* Only one of them can handle setup/teardown.
Now, I wonder. What if we make it so it CAN inherit? We need 3
examples, where something is in A, A&B, and B. We will get to
that. iA and iB are the class/structs and A/B/C are the
methods/functions. So...
//original based on...
class iA {
void A();
void C();
}
class iB : iA {
void A();
void B();
}
Breaking them down for structs we have:
struct base_AB { //the 'manager' that does redirection and known
size
char type = 'A'; //polymorphic type identifier, for simplicity
//shared 'parent' baggage ie -> iA
//baggage space for iB
//Exists in both iA & iB
void A() {
switch(type) {
case 'A': (cast(iA) this).A(); break;
case 'B': (cast(iB) this).B(); break;
default: throw new Exception("method A() invalid for struct
type:" ~ type);
}
}
//B only exists in inherited
void B() {
if (type == 'B') (cast(iB) this).B();
else throw new Exception();
}
//C exists everywhere
void C() { (cast(iA) this).C(); }
}
So far the base is easy to make, now however as for how iA and
iB interact with eachother... Ignoring infinite loops problems:
struct iA {
char type;
//baggage - Size must be identical to base_AB
void A() {
A();
//B(); /*iA doesn't really know about B so can't call it from
here... not safely anyways*/
C();
};
}
Now, C() can be called regardless of the type (no checks
needed). iB.B() can also be called anywhere in iB with no
problems, but it would be simpler if all calls regardless went to
the base and let the base handle it. (Optimizations would
probably remove unneeded checks later).
struct iB {
char type; //and other baggage
void A() {
A(); // actually: (cast(base_AB) this).A();
B(); // actually: (cast(base_AB) this).B();
C(); // actually: (cast(base_AB) this).C();
}
void B() {
//ditto as A()'s
}
}
This can probably be easily done having a different naming set
which handles the redirection, but the names and boiler-plate
seems unnecessarily large and verbose for a simple task;
Optimization will likely remove the excess unneeded portions in
final binary form anyways.
//different name examples:
struct base_AB {
char type; //and other baggage
void A() {
switch(type) {
case 'A': (cast(iA) this).realA(); break;
case 'B': (cast(iB) this).realB(); break;
default: throw new Exception("method A() invalid for struct
type:" ~ type);
}
}
struct iB {
char type;
//bagage
//boilerplate
void A() { cast(base_AB) this.A(); }
void B() { cast(base_AB) this.B(); }
void C() { cast(base_AB) this.C(); }
void realA() {
A();
B(); //Path really is now: this.B() -> base_AB.B() ->
iB.realB();
C();
}
void realB() { /* ... */ }
}
Now how would one build it without all the extra boilerplate
overhead (also preferably with fewer confusing elements) Three
ideas are coming to mind.
1) Template. This can work but it's a lot of overhead, a lot of
work and is hard to keep track of. I have an experimental version
that semi-works but can't be used seriously. My project sorta
relying on this has come to a halt for the moment. It's also very
finickle where data (and struct order) are involved and refuses
to compiler out of a certain order. Also for calling functions
that exist in current structs require you to forcibly call 'this'
or go around it in order for it to do the redirections elsewhere.
2) UDA's could be possible, if you tag a struct as belonging
and then scan/add the appropriate code. But this seems like a lot
of work and overhead. Probably won't work, plus a new UDA for
each type vs known fixed extensions. Seems like a lot of extra
work. Maybe?
struct base_AB @LSP(iA, iB) {}
struct iA @LSP_base(base_AB) {}
struct iB @LSP_base(base_AB) {}
3) Compiler. This seems the most likely (and 95% of it is
already in place for classes), but i can't implement it myself
easily; Plus i am not sure if Walter or Andrei would want/allow
it. If you squint your eyes you can see it looks very similar to
the original struct/class formula for C++ (without using
pointers/new), except that the total size reserved is known/set
in advance to incorporate all types (fixed size, no
growing/shrinking by casting).
Perhaps introducing a third base type (so struct, classes and
LSP's)? This might help but depends on the amount of extra
complexity would be needed, or how many bugs it could
introduce... or incorporate it as the normal struct but is a
experimental/disabled feature unless you apply a certain
attribute (or set of?)
If there's a suggestion of how to make this work and feel more
natural (class-like without allocation/pointers) then
suggestions/ideas would be nice. It's possible this type of
feature is just not wanted. But I'm willing to bet there's quite
a few places this type of feature/set could be utilized when you
consider what it can be used for.
