You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Global variables are visible across the module that they are defined and also visible to external modules, if they are defined as public variables/constants. The concern with global variables is that they can be defined in one bal file, but can be accessed from any other bal files within that module without knowing which bal file it is defined. But when we are mapping this at JVM level, the classes need to know the class that the global variable/constants are defined.
Design considerations
We can separate the global variable definition and initialization part.
The definition of the global variables can be in the same class file as with bal file mapping.
The initialization (assigning values) can be in a common class file per module. This class will have a method which contain all the global variable initialization for that module. This is similar to the package functions at ballerina level.
Similarly, the same approach can be followed for imported modules, where, for each module, we will be generating a java package and the global variable initialization can be in a common class file per each module.
The ordering of invocation of this variable initialization classes will be based on the same order that the BIR produces.
This ordering will produce the correct initialized values for the global variables.
Need to check on how to get line number info for global variable that have function invocations.
This initialization class should be invoked using a startup routine (crt0) when the jar file is being executed.
The important point to note that, there should a mapping generated for global variables names against the class names in which those variables are defined. This mapping will be used when compiling the user code which has references to these variables.
The text was updated successfully, but these errors were encountered:
Global variables are visible across the module that they are defined and also visible to external modules, if they are defined as public variables/constants. The concern with global variables is that they can be defined in one bal file, but can be accessed from any other bal files within that module without knowing which bal file it is defined. But when we are mapping this at JVM level, the classes need to know the class that the global variable/constants are defined.
Design considerations
The text was updated successfully, but these errors were encountered: