 |
AngelScript
|
|
|
AngelScript
|
|
The library's version number is composed of 3 numbers, and sometimes an additional letter. Examples:
The first number is the major version. This is updated whenever there is a major redesign, or a major milestone happens. When this number is changed backwards compatibility is not necessarily maintained by the library.
The second number is the application interface version. This is updated whenever there is a change in the interface, e.g. a new method is added or an existing method has its signature modified. Usually the change is incremental so that there is no need to modify the application code unless the new functions are wanted, but a recompilation is still necessary. Sometimes parts of the interface are deprecated, but whenever possible the deprecated parts can be turned back on through a compile time flag.
The third number is the minor version. This is updated when the back-end logic in the library is modified, e.g. adding or modifying a script language feature, but no interface change is done. No change in the application code should be required during an upgrade when only the minor version has changed.
The additional letter is used when the change is purely bug fixes. In this case the binary application interface should be untouched, so an application that loads the library as a shared object (dll) should be able to upgrade the library without recompiling the application.
The following is a bit of history for the library that shows how it has evolved since the beginning to the current date. The complete change list can be found on the AngelScript site and in the SDK.
The library was first conceived in early 2003, with the first working (internal) version available in March, 2003.
At the end of June, 2003 the library's first public release with version 1.0 was made.
In the beginning of 2005 I made the difficult decision to do a major change of direction. Version 1 had several flaws that I couldn't solve without a major redesign. The worst was that the script language wasn't properly sand-boxed, i.e. the script writer had to be careful when writing scripts in order to crash the application or cause worse problems. The script compiler didn't make any attempts to guarantee that a value passed by reference to a function actually stayed alive during the call, and the script was allowed to use and manipulate pointers to access memory directly.
Version 2.0 included the concept of object handles, @, and parameter references with direction keywords, i.e. in & out. Object handles are basically smart pointers that the compiler uses to guarantee the proper life time of objects, and the direction keywords for parameter references are used to tell the compiler what the reference will be used for. This in turn allows the compiler to take necessary actions to guarantee the lifetime of the value, e.g. to create a temporary object that will receive the output value, which will only be assigned to the final destination after the called function returns to the caller.
With the release of 2.2.0 in mid-2005 the script language got its first version of script classes, at the time called struct. Before this the script language didn't support defining any new types, and scripts could only implement global functions for interacting the built-in types as well as application registered types.
With the introduction of classes the need for the incremental garbage collector was also born, as the scripts could now create objects with circular relationships that the simple reference counting memory model couldn't handle by itself.
In 2006, with the release of 2.7.0, the concept of interfaces was introduced in the script language. Allowing the application to register a script interface that the script class could implement made for an easier interaction between application and script.
Only in 2009, with version 2.15.2, was class inheritance implemented, though only single inheritance, to avoid complicating both the library and script language. Multiple interfaces are still allowed to support polymorphism.
Still in 2009, with version 2.16.1, the the library added support for registering templated types, to allow the application to create its own custom container types. The built-in array type would eventually be completely replaced by this and a default array add-on is provided.
With version 2.16.3 the script classes were enhanced to allow implementing operator overloads, thus making the language even more flexible and powerful.
Version 2.17.0, released in August 2009, introduced an interface to support external JIT compilers. While the AngelScript library doesn't provide its own JIT compiler, a third party JIT compiler was soon created with quick adoption by the community.
Support for function pointers in the script language was added in 2010 with version 2.18.2. Now the application can allow scripts to setup its own callbacks.
With the release of version 2.21.0 in 2011 the script engine gained support for automatic garbage collection to simplify this task for the application developer. Of course, the application developers that prefer to have full control can still do it manually by turning off the automatic collection.
This release also saw the implementation of a first standard debugger add-on that can be used by applications to add support for stepping through the scripts and inspecting variables for proper run-time debugging.
Namespaces were added to the script language in 2012 with version 2.22.2.
Mixin classes were introduced with version 2.25.0 to provide better support for code re-use even without multiple inheritance.
The template types that were first introduced in 2009 were enhanced with version 2.26.1 to support multiple subtypes in order to give greater flexibility for the application.
Support for delegates was added with version 2.26.3.
Version 2.27.0 included support for weak references, so that is possible to have greater control over which handles keep objects alive or not.
Support for registrable factory functions that takes initialization lists was added in 2.28.0. This allows the application to define the specific pattern that should be used for different types using a simple syntax.
In version 2.29.0 the script language gained support for named arguments, and auto for automatically determining the type of variables based on the initialization expression.
Anonymous functions were first implemented in version 2.30.2.
Funcdefs can be declared as members of classes as of version 2.31.0.
The external keyword was introduced in version 2.32.0 to explicitly include shared entities from a previously compiled module. This version also introduced anonymouus initialization lists for more compact scripts.
In version 2.33.0 the language was improved to support try-catch statements, and for flagging constructors as explicit for better control over what type conversions can happen implicitly.
With version 2.34.0 virtual property access must be explicitly flagged with the property keyword so that functions starting with get_ or set_ won't automatically be interpreted as virtual properties.
1.8.18