I’ve decided that the keyword ‘delegate’ wasn’t needed. It can be just just a normal class (properties, methods etc.) and acts as the default state. States use a class as a basis and can’t have any properties. I think :default goes back to the default state… or the name of the class… mmm. The class name sounds good.
Archive for the 'Projects' CategoryPage 2 of 3
While we are still working on our php system we aren’t adding any new features because we want to get it finished and out the door. This said I’ve started a list of the features that we want in version 2.0.
- Templates
- Sub-modules (more dynamic moduleloader)
- Blog module
- RSS for content and blog
I’m salivating already.
I think I’m going to write a recursive-decent-parser for voodoo; flex and bison would need a hefty kick in the pants to work with a tab-blocked language.
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.
A game language would benefit greatly from a state based mechanic, such as delegates. Basically these are objects whose classes can be changed at runtime.
A light example:
delegate light
- void toggle()
- boolean status()
state on:light
- void toggle()
state off
- boolean status()
return true
state off:light
- void toggle()
state on
- boolean status()
return false
I’m not entirely sure about the syntax for changing states, it could either be setting a certain property, a method call or a keyword call as shown. Either way, this is quite cool.
I’m also not sure about inheritance, can a delegate ’subclass’ another delegate? What about states?
Either way, states can’t add any extra methods or properties to the class.
Oh, and they are fast because all they do is replace the class, so this is a good way to multiple functions without if statements all the time.
My virtual machine is going to use a similar ‘constant pool’ to java and this can be linked dynamically or statically on load. Also I talk in the 2nd and 3rd person a lot… sorry. So with that in mind, this is the most recent question that I’ve asked myself.
We need a way of loading and unloading scripted bits of functionality faster than the complicated re-linking (or whatever I decide on) method. It would be very nice (ie I won’t settle for less) for this to be dynamic and automatically upkept. If a series of groups are written in such a way that reversing the order and unloading won’t change the offsets for any other part of the code base, this should happen automatically.
I think a good way to do this is for each class to have a stack of groups that have modified it, if the group that we are trying to unload is at the top of every stack of every class then we can unload it automatically. Also if we are the last group in the stack we should delete the class, but we need no instances of it in existance (may be hard for classes with static instances?).
I haven’t completely worked out the specifics yet (the class hierarchy will get in the way) but I think it will work.