Tuesday 19 July 2011

Type object interface

A better interface would be to use containers. I've always considered types to be reflectable on and always planned to include static reflection in the language. One of the primary reasons I wanted to move to a types-are-objects system. In this case, it could be considerably easier to define the interface as containers. You could consider "type" as a type, like

class type {
public:
    std::map(std::string, type) private_variables;
    //... and more
};
type MyClass = new type;
MyClass.private_variables.insert("MyArray", int.array(10));
MyClass.public_functions.insert("operator[]", [](this, index)
{
    return forward(this).MyArray[index];
});


This will trivially extend our API to allow for having a good look in what's in those containers right now. The thing is that I definitely do not want language primitive types to be defined in terms of library types. I want a strict separation between language and library- no std::type_info in "DeadMG++". Even if I supposedly encapsulated the type, in reality any Standard library would have to follow it's conventions.

I guess the reality is that unless I move a whole bunch of library stuff into the language, it'll be impossible to separate the two. I should just do my best to specify as little as possible about the implementation of type.

No comments:

Post a Comment