Limited Semi-PolyMorphic (LSP) structs?

[qznc]

On Monday, 26 August 2013 at 11:20:17 UTC, Era Scarecrow wrote:
>  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();
> }

Hm, my try would be alias this for inheritance and function 
pointers for virtual methods.

struct iA {
   void function(iA) A;
   void C();
}

struct iB {
   iA _a;
   alias this = _a;
   void B();
}

If you have multiple "subclasses" for iA, you can use a 
tagged-union from std.variant.