New programming paradigm

[EntangledQuanta via Digitalmars-d-learn]

On Thursday, 7 September 2017 at 19:33:01 UTC, apz28 wrote:
> On Thursday, 7 September 2017 at 17:13:43 UTC, EntangledQuanta 
> wrote:
>> On Thursday, 7 September 2017 at 15:36:47 UTC, Jesse Phillips 
>> wrote:
>>> [...]
>>
>> All types have a type ;) You specified in the above case that 
>> m is an int by setting it to 4(I assume that is what var(4) 
>> means). But the downside, at least on some level, all the 
>> usable types must be know or the switch cannot be 
>> generated(there is the default case which might be able to 
>> solve the unknown type problem in some way).
>>
>> [...]
>
> Nice for simple types but fail for struct, array & object
> Current variant implementation is lack of type-id to check for 
> above ones. For this lacking, is there a runtime (not compile 
> time - trait) to check if a type is a struct or array or object?
>
> Cheer



On Thursday, 7 September 2017 at 19:33:01 UTC, apz28 wrote:
> On Thursday, 7 September 2017 at 17:13:43 UTC, EntangledQuanta 
> wrote:
>> On Thursday, 7 September 2017 at 15:36:47 UTC, Jesse Phillips 
>> wrote:
>>> [...]
>>
>> All types have a type ;) You specified in the above case that 
>> m is an int by setting it to 4(I assume that is what var(4) 
>> means). But the downside, at least on some level, all the 
>> usable types must be know or the switch cannot be 
>> generated(there is the default case which might be able to 
>> solve the unknown type problem in some way).
>>
>> [...]
>
> Nice for simple types but fail for struct, array & object
> Current variant implementation is lack of type-id to check for 
> above ones. For this lacking, is there a runtime (not compile 
> time - trait) to check if a type is a struct or array or object?
>
> Cheer

No, it is not a big deal. One simply has to have a mapping, it 
doesn't matter what kind of type, only that it exists at compile 
time. It can be extended to be used with any specific type. One 
will need to be able to include some type information in the 
types that do not have them though, but that only costs a little 
memory.

The point is not the exact method I used, which is just fodder, 
but that if the compiler implemented such a feature, it would be 
very clean. I left, obviously, a lot of details out that the 
compiler would have to due. In the protoypes, you see that I 
included an enum... the enum is what does the work... it contains 
type information.

enum types
{
    Class,
    Float,
    Int,
    MySpecificClass,
}

the switch then can be used and as long as the actual values 
'typeid' matches, it will link up with the template.

You can't use types directly, that would be pointless, they have 
to be wrapped in a variant like type which contains the type 
value. e.g.,

struct Variant(T)
{
    types type;
    T val;
    alias this = val;
}

which is a lightweight wrapper around anything. This is basically 
like std.variant.Variant except the type indicator comes from an 
enum. Again, this simplifies the discussion but it is not a 
problem for classes, structs, enums, or any other type, as long 
as they exist at compile time.


I only used std.variant.Variant to simplify things, but the 
compiler would have to construct the typeid list internally. (I 
did it in my add explicitly for the types I was going to use)


As far as runtime checking, no, because bits are bits. You can 
cast any pointer to any type you want and there is no way to know 
if it is suppose to be valid or not. This is why you have to 
include the type info somewhere for the object. classes have 
classinfo but there would be no way to validate it 100%.