From 5ef1ca73901e9b4e2b4d11e8a09474ae64c08c5a Mon Sep 17 00:00:00 2001 From: Menarul Alam Date: Tue, 3 Oct 2023 15:22:06 -0700 Subject: [PATCH] changes --- rfcs/require-by-string-aliases.md | 33 +++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/rfcs/require-by-string-aliases.md b/rfcs/require-by-string-aliases.md index 320460b2..0fa5f70d 100644 --- a/rfcs/require-by-string-aliases.md +++ b/rfcs/require-by-string-aliases.md @@ -197,17 +197,34 @@ This allows us to refer to other subprojects like this, regardless of the exact ```lua local subproject1 = require("com.roblox.luau/subproject-1") ``` -## Roblox Specifics +### Roblox Specifics In the Roblox engine, a similar aliasing system could be implemented. Assuming a central package management system were available, a Roblox Script could contain local Roact = require("Roact"), and everything would "just work". -# Drawbacks +## Drawbacks ## Backwards Compatibility This alias system introduces a new layer to require that wasn't previously there. However, the advantages of this system are expected to outweigh the complexities it introduces. -# Alternatives -## Different Ways of Defining Aliases -### Defining Paths/Aliases Directly in the Requiring File -This approach has several drawbacks, such as making the code less clean and complicating the task for package managers. +## Alternatives -### Defining Configuration Files in a Non-JSON Format -Alias maps could alternatively be defined in specially named .luau files, but using JSON is simpler and more standardized. +### Different ways of defining aliases + +#### Defining paths/aliases directly in the requiring file + +Rather than defining paths/alias maps in an external configuration file, we could alternatively define paths/aliases directly in the files that require them. For example, this could manifest itself through an extension of the `--!` comment syntax or introduce new syntax like `--@ = @`. +```lua +--@"Roact" = @"C:/LuauModules/Roact-v1.4.2" +local Roact = require("@Roact") + +-- Same as this: +local Roact = require("@C:/LuauModules/Roact-v1.4.2") +``` + +Some potential issues with this approach: +- Could lead to Luau file headers becoming cluttered. +- Would probably lead to substantial copy-and-pasting between modules in the same library, as they would likely need to share certain paths/aliases. +- Using configuration files for paths/alias maps allows modules to share aliases while still providing the flexibility to override if needed. This approach does not support inheritance and overriding in an obvious way. +- Removes the layer of abstraction that is provided by external paths/alias maps. This might also blur the scope of package managers. The software would need to directly modify lines of code in `.luau` files, rather than modifying configuration files. + +#### Defining configuration files in a non-JSON format + +Alias maps could alternatively be defined in specially named `.luau` files themselves, or at least adhering to Luau syntax. This approach is somewhat unappealing, however, as it would require package management software to parse Luau syntax. JSON syntax is well-understood and well-supported, which would likely facilitate the development of package management software. \ No newline at end of file