This is just a fairly brief update. I’ve finished the huge assignment… that’s out of the way. I’ve started working on a website for the developer of a quite cool game, will post when I’ve finished.
Also I have a long running shopping system to work on, I really want to get it out of the way.
Hopefully I can squeeze some time into voodoo this break… I’ve done everything (for now) that’s required for uni.
Update on delegates:
The delegates themselves can subclass other delegates but states can only have a delegate as a parent, and so can only be one class deep. I think this is the way it’s going to stay, but I can’t help wondering if states need to be passed down the hierarchy. If you subclass ’switch’ and created a new switch that requires two calls to toggle to change states, you will probably want to reason about what state a generic ’switch’ is in wether or not it’s a ‘double switch’ or a normal one. The current way to do this is to have a method that returns a boolean or something similar depending on what state it’s in. States could become mandatory to implement as you go down the classes - every switch needs an on and off state. But then this gets annoying, because you might not want to have to implement the states.
The way I’m going to program with this language is to have shallow class hierarchies so it shouldn’t be too much of a problem.
I think that a ‘delegate’ is the entrance point, you never really deal directly with the states. A delegate is a class that can have different functionality.
For when I start work on the parser / compiler… would it be an error to create a container (variable) that can only hold one specific state? I’m having trouble figuring out a situation where that would be good. So for the moment… no, only delegate containers.