Software Development

I modified the way my type system works. Yet again. Funny how things look so good on paper and then when you try to implement them, all hell breaks loose. I now have two kinds of types. The first is the regular kind of type that has an ID. If you compare two types and they have the same ID, then they are the same type. I wish the entire type system were this easy. Because I will have an IDE, overriding properties cannot be merged directly into a single structure (though that happens on a temporary basis). I need to keep a copy of the original. And how do you override properties? By using modifiers.

The second kind of types are these modifiers. You derive a type by using a modifier and change whatever property or member you want. You can do the same with types. You can use one type to derive another type and change the base type's properties.

Modifiers can add or remove properties, but you can only define type operations on types, not modifiers. So adding properties may be useless if you use modifiers. Another difference is that modifiers can only have one base type while types can have any number of them. IOW, types can use multiple inheritance while modifiers use single inheritance. You can inherit from either one in any way you want just as long as the inheritance rules are maintained.

Handling all these things is what I did today. There's actually another kind of internal type called an XType. It merges all modifiers going up its base until it reaches a type (which is also merged). We put all properties, members and other info into one XType structure. I call this "collapsing" a type. These are temporary and are used for a few different type operations. This part is also coded up. If you want to compare XTypes, you have to compare all their properties and members. So that's what I will do next time I get at it. I'd like to code it up now, but I've been coding all day (typing non-stop). I'm writing this blog entry now to make sure it makes sense when describing it.

One thing that may be odd is the following example. Say you have type X that derives type Y, you cannot use an instance of X where it requires an instance of type Y. If you want to do this, you must supply a conversion component from type X to type Y and use that. The reason is that instances are independent entities. Once created, they are no longer dependent on their ancestors. You can even spawn off new instances that are modified versions of the current instance. This is done through the use of modifiers as mentioned (or even through new derived types). Note that this can happen at runtime on another machine, in another era, in a time where the original definitions are long gone.

All this is also consistent with the fact that values are derived types. It also makes sense that values only have ONE base type exactly like modifiers. And values are indeed stored in modifiers though types can store default values as well.

So if you have 4 as a derived type of Int32, I think it's the right decision to not be able to use 4 where you can use Int32. Now, as I said before, if the output is actually hardcoded to 4 and an input is Int32, then obviously their types do not match. But I said there's another condition that can make this work. If the output is a value of the input, then it's ok. And indeed 4 is a value of Int32 and the link can be applied. This is also how enumerations work. You can have a set for the input and if the output is one of them, then the link can be made. But if I compare types, they will not be equal.

I don't know why, but there's something I find immensely appealing about not allowing subtypes for inputs (other than values). At first, I thought there might be a problem with this. What if I want to use an entity somewhere that expects a base type? What do I do? Well, it just so happens that any ONE item can only be used by exactly ONE component. Virtual methods and classes are fine when an object can be used by many locations. But in data flow, an input will only come from ONE output. There need only ever be ONE representation. Polymorphism is useless in this case. It's more than useless. It's actually detrimental.

So I'm literally days away from implementing the runtime. I can't wait. Still, I expect a few weeks to do this. The runtime needs to deal with sockets, concurrency, serialisation and protocols. Most of this I've already built, but I'll need to change a few things. Putting it all together will require some extra work there. Yes, I know I keep saying I'm weeks away. But I am making real progress again. There are WAY more parts to this system than I ever envisioned. Luckily, the runtime should be rather simple. I'll try to make this week a good one.