[color=#000000][font=Arial]

This new version brings a couple of enhancements to the script language: shared global functions and namespaces. The shared global functions is a continuation on the shared feature from version 2.22.0.[/font]
[color=#000000][font=Arial]

The namespaces is a new feature in the language, which is based on the C++ namespace feature. It is still in its initial stages, so some things you can do in C++ is still not available in AngelScript, e.g. 'using namespace'. Also, the application interface has not yet been changed, so the application doesn't really have all the methods necessary to interact with namespaces.[/font]
[color=#000000][font=Arial]

I've also made some internal improvements in the library. Mainly with the goal of finally making the pre-compiled bytecode fully platform independent. I've implemented some new bytecode instructions that are exclusively for manipulating pointers, and with this some older bytecode instructions have also been removed as they ended up no longer being used.[/font]
[color=#000000][font=Arial]

For the next version I plan on implementing the interface changes necessary for interacting with namespaces. I also plan to continue working on making the pre-compiled bytecode platform independent. I specifically want to focus on removing the dependency on the CPU pointer size, which is one of the few last obstacles to gaining full independence.[/font]
[color=#000000][font=Arial]

Another thing I'll implement for the next version is the option to compile the library without the script compiler. By not including the compiler the applications that only rely on pre-compiled bytecode should be able to reduce the executable size quite a bit.[/font]
[color=#000000][font=Arial]

Regards,[/font][color=#000000][font=Arial]

Andreas[/font]

So happy to see namespaces implemented. Now I can cut it out with the crazy hacks to organize global script objects.

As for the interface, what is it you had in mind? Because a change like this could potentially break alot of existing code. However, something like a modal interface could work.

engine->SetNamespace( "Herp" );
engine->RegisterGlobalProperty( "Derp@ FooDerp",fooderp_pointer ); // Becomes Herp::FooDerp
engine->SetNamespace(); // Leave blank to go back to the global namespace.

adam4813:

I plan on adding an option for application managed references in the next release. virious already contributed an implementation towards this and I'll integrate and test it.

Personally I cannot really recommend this as I see it as a potential memory leak issue, or worse, adding risks for dangling pointer problems. Still, I won't let my personal opinions get in the way here, as I know a lot of people want to simply allow the script to access a pointer with no extra fuzz.

Between using smartpointers and empty addref/release behaviours, I'd use the latter as it is much, much easier to implement, and they will behave pretty much identically to the application managed references.

ekimr:

My intention for the interface changes is similar to what you suggested. I definitely do not want the introduction of namespaces to break current implementations.

W00t, nested namespaces work as well!!!

namespace R {
namespace Images {
Resource_Image@ MainMenu = Resource_Image( "Resources/Images/MainMenu.png","MainMenu",512,512);
Resource_Image@ Groucho = Resource_Image( "Resources/Images/groucho-fire.jpg","Groucho",500,340);
} // namespace Images
namespace Spritesheets {
Resource_Spritesheet@ Character = Resource_Spritesheet( "Resources/Spritesheets/Character.json","Character");
} // namespace Spritesheets
namespace Fonts {
Resource_Font@ Console = Resource_Font( "Resources/Fonts/Inconsolata.otf","Console");
} // namespace Fonts
} // Namespace R

I love code generation. =)