This is all just out of curiosity and love for AS, nothing more :) In the last year or so we've seen some truly major improvements and additions to Angel Script:
Classes
Property style getters and setters
JIT framework
ect... And now that most of that is coming to a close, what are the next big features? Looking at the road map, it appears to be:
Removal of the built-in array type
Unified type info system
Scripts being truly dynamic (able to be built and run much like LUA or PHP)
Unicode support
Are those the next big priorities? Or what do you have in mind witchlord? JIT and Classes were total game changers, and now AS is starting to become well rounded and filled out, there doesn't seem to be many more big ticket items like that, which will fundamentally change the way AS can be used. I Personally see everything being truly dynamic, as well as Unicode support being the next big things. After that how will the language evolve and change I wounder? Getting a x86 and x86_64 JIT sure would be a big deal. What do other people want to see as the next big feature? [edit] As a side note, one thing I'd like to see is "initialize to zero values" for all variables, this is just a nice "safety" feature that all high level languages should have IMO. Makes things easier and safer for the script writer. [/edit]
First I'd like to say that full unicode support is already available. Though only with UTF8 encoding so far. Support for UTF16 encoding may be added in a future version, but has a low priority.
The removal of the built-in array type is not really a feature in itself, but will be done as soon as the template types have the necessary support for completely substitute the built-in array type. I still need to implement support for initialization lists and a callback behaviour to validate the template instanciation at compile time. Another improvement needed for the template types is the support for multiple subtypes, so that map structures can be built easily.
The next big thing is the true dynamic scripts modules. It will allow the application to incrementally build up modules as functions and global variables are declared. It will also be possible to remove already declared functions and global variables from the scope of the module in order to make room for new defitions of the same.
This feature will also allow me to add support for function pointers and self-modifying scripts. The built-in ExecuteString method will also be removed when this support is added. Instead an add-on will be provided for that support.
At the same time, the application registered interface shall become more dynamic, so that global properties, functions, and types can be registered and unregistered individually (without the need for config groups). It shall be possible to unregister parts of the interface even if there are still scripts that access those parts. Obviously the scripts will fail with an exception in that case, but the application shall not be forced to manually abort all scripts that may or may not be accessing the registered functions before removing them.
This feature will improve support for applications that use more dynamic interface, e.g. through plug-ins, etc.
Version 2.18.0 will see the beginning of these features, but they will probably be gradually built up as future releases are made.
Another big feature I wish to implement in the near future is better support for pre-compiled bytecode. I plan on splitting out the compiler into a separate object, so that it will be easier for an application to exclude this code if it won't be used, i.e. if the application will only load pre-compiled bytecode. I also intend to make the pre-compiled bytecode 100% platform independent, though I'm not quite sure how this will be done yet. I'll probably end up producing some intermediate code, and then have a second pass to transform this into platform dependent code (or directly to JIT native code).
I would also like to expand the add-ons more, to make it even easier to get things going. One thing that I would really like to see implemented is support for a debugger add-on. It should be a class that have all the necessary methods for examining call stack and variables, as well as setting break points and stepping through the code. This class should be called by the application's built-in console, or could be coupled to a network interface to provide remote debugging support.
These are my near future plans. But I would very much like to see what the community thinks would be the most important features to implement first.
I'm actually not too sure it's all that useful. AngelScript already makes sure all object variables are initialized to zero (or their default constructor), so there should not be any fear of doing something harmful, as you will never have any dangling pointers, etc. As for primitive types, rarely do you actually want to initialize them to zero (not counting the variables used for loop iteration) so you wouldn't really gain much by this. Besides, making sure all variables are initialized to zero when they come into scope would also require some extra processing.
Still, I'm not totally against it. I agree with having always predictable results, so if I can make this a feature that can be optionally turned off for a performance boost I'll probably do it. It is quite low priority though, and does require quite a bit of changes, so don't expect it to be implemented soon.
I'm sorry if this disappoints you, but hopefully you'll understand.
I look forward to having all the functionality necessary in the low-level for hot loading scripts at runtime. It will make things a little easier for our designers and scripters for tweaking.
[We used to have hot loading support, done at a high-level, but it was very fragile, and once I put in some improvements to our high-level, I removed hot loading support, as it was too complicated to maintain]
