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
Is your feature request related to a problem? Please describe.
Currently, the only way to share values between Amber files (i.e. the global scope) is to declare an environment variable. This has the disadvantage of hindered discoverability: There is now a shared assumption being the name of the variable, which escapes compiler analysis.
Describe the solution you'd like
The ability to specify pub let ..., which makes the Amber variable into a singleton, which can be imported into any other file that requires it.
The technical aspect would likely involve reusing the same internal name across importers of the variable in the compiled script.
Describe alternatives you've considered
As above, an environment variable works, but the lack of compiler analysis makes it a possible avenue for issues.
An alternative is to export a getter/setter for the scoped variable, but it is unclear whether successive imports of a file preserve the required scope.
Fully global variables are a possible solution, but the module relationship isn't explicitly stated as it would with an import.
Additional context This is what I'm currently working on. This suggestion would replace instances of env_var_get(), in src/cli.ab for instance, allowing it to import values loaded in src/main.ab
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, the only way to share values between Amber files (i.e. the global scope) is to declare an environment variable. This has the disadvantage of hindered discoverability: There is now a shared assumption being the name of the variable, which escapes compiler analysis.
Describe the solution you'd like
The ability to specify
pub let ...
, which makes the Amber variable into a singleton, which can be imported into any other file that requires it.The technical aspect would likely involve reusing the same internal name across importers of the variable in the compiled script.
Describe alternatives you've considered
As above, an environment variable works, but the lack of compiler analysis makes it a possible avenue for issues.
An alternative is to export a getter/setter for the scoped variable, but it is unclear whether successive imports of a file preserve the required scope.
Fully global variables are a possible solution, but the module relationship isn't explicitly stated as it would with an import.
Additional context
This is what I'm currently working on. This suggestion would replace instances of
env_var_get()
, insrc/cli.ab
for instance, allowing it to import values loaded insrc/main.ab
The text was updated successfully, but these errors were encountered: