The first thought about adding this support comes down to end-user syntax. We have a couple of options for this; the first is to declare consts similar to how you would in C++:-
This is intuitive to C++ programmers, but in the end I believe it'd be much harder to implement and can cause issues when using them in tables eg:
mytable = table( const
It's just plain dirty.
The second option is to provide a 'const' type which itself holds a value and will enforce how it's allowed to be changed. So now we're looking at a syntax such as:
I believe this option sits better with GMScript itself and is easier to use in normal coding.
mytable = table(
myint = const( 50 );
I've decided to make an extension to GMScript to add in this const support, mainly because I feel as if I NEED it for GMGX. Maybe not right now, but when it goes public I don't want people to make stupid errors which kills things for them.
So the first port of call is to go through and add support for a native const type. This is harder than it sounds as the basic types are EVERYWHERE in GMScript. Here's my plan:
- Upgrade the Scanner
- Upgrade the lexxer
- Add a native gmConstObject class and wire it up to gmMachine
- Add in support for gmConstObject assignment in the gmVariable
- Add in the native binding for the new const object
- Update the code generator to recognise the new type
- Add in a new bytecode instruction
- Update the gmThread execute function to validate assignment operations on local const objects
- Update the gmTableObject 'Set' method to verify assignment operations on table-bound const objects
There's probably a bunch more, but as you can see it's hardly a trivial task. We have an interesting dilemma from this - we only want to be able to update const variables from the native API that GM gives us, however this same API is used by GM internally (at least for table variables). I'll find a way...