shared by default

Started by
5 comments, last by WitchLord 6 years, 5 months ago

Is it possible to get angelscript to regard everything shared by default, instead of manually adding "shared" to everything?

What are the reasons to not declare things shared?

One reason I can think about is being able to use global variables.

 

Also is there a way to achieve global shared variables?

Advertisement
Quote

Is it possible to get angelscript to regard everything shared by default, instead of manually adding "shared" to everything?

Not without customizing the library. Why would you want to make everything shared by default? 

Quote

What are the reasons to not declare things shared?

The global variables that you mentioned is one reason.

The fact that if everything is shared you'll have difficulty in creating unique logic in separate modules is another.

If everything is shared, then why not just put everything in a single module and be done with it.

Quote

Also is there a way to achieve global shared variables?

Not at the moment. Support for global shared variables has not yet been implemented. It is on my to-do list though.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

The reason for wanting to make things shared is to allow extending the scripts without modifying them, for example having to modify existing scripts to include new script files.

If I make everything shared, users should be able to access things from their own script modules.

Another approach to achieve this with a single script module is making a way to automatically include script files (ex. include everything from a directory). It seems to make things simpler but also feels more "hacky" than using a language feature.

I'm not sure which approach will be better for preventing users from having to modify files - shared everything or auto include (or something else?).

Including everything from a directory into a single module when compiling sounds like a much easier and less restrictive solution than trying to make everything shared across modules.

Your application can easily list all the files in the directory using a name mask (for example *.as) and include each of them as a separate script section (AddScriptSection) in the module before calling Build.

The #include directive is not really part of the core language. It is implemented by the application, if desired. The standard add-on ScriptBuilder has a simple implementation that you can use as a base to write your own custom solution.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic drew my interest because I had a related idea. In our application it's relatively common to create script files that serve as libraries to be #included. Although not everyone follows this trend, typically it makes sense for all or most of entities in those files to be registered as shared. They may get big and be included by multiple modules, so it probably saves some compilation time, and in case users want to implement any type of interaction between modules involving the entities, they don't have to modify the library file or come up with workarounds.

As such, I have written files that have over a hundred occurrences of the "shared" keyword, at the beginning of every declaration that allows it. This is a really minor inconvenience but occasionally it gets in the way, such as when I initially forget to add it and have to insert it in several dozen lines, or when I want to temporarily make all entities non-shared to test something. It also looks too verbose to my liking.

Because included files are also typically wrapped in a namespace, my idea to solve this was the following syntax:


shared namespace ns { // shared namespace automatically declares all entities in corresponding block as shared
  class Object {} // Object is shared class
  void func() {} // func is shared function
  funcdef void VoidFunc(); // funcdefs are allowed in shared namespace blocks and act as always
  typedef double float64; // same applies to typedefs
  //int n; // error: variables cannot be shared
}
namespace ns { // being shared is not a property of the namespace itself, only of a particular namespace block
  // different namespace blocks with the same name may be declared as non-shared
  class Derived : Object {} // Derived is not shared
  shared int zero() {} // shared declaration in non-shared namespace block still allowed
  funcdef int IntFunc(); // funcdefs shared by default
  int n; // ok: n is not declared as shared
}

However, without support for anonymous namespaces, this might be quite inconvenient in instances where a named namespace is undesired, so later I also came up with a simpler, minimal syntax:


namespace ns {
  shared {
    class Object {}
    void func() {}
    funcdef void VoidFunc();
    typedef double float64;
    //int n;
  }
  class Derived : Object {}
  shared int zero() {}
  funcdef int IntFunc();
  int n;
}

I think implementing one of those or a similar syntax would be helpful.

That looks quite nice. I'll add it to the to-do list for a potential future implementation,

Thanks for the suggestion.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic is closed to new replies.

Advertisement