Method and system for visibility control of programming language scopes

Abstract

This invention discloses a method and system for controlling the visibility of programming language scopes. The method includes: during the execution of program code, when an execution operation on a program entity is detected, determining the target scope chain corresponding to the program entity based on the entity type; searching for the program entity level by level from the current scope of the program code to the last-level scope of the target scope chain until the program entity is found, thus determining the target scope where the program entity resides; and calling the program entity from the namespace corresponding to the target scope. This solves the problems of low code maintainability and poor code security. By setting more refined and hierarchical scopes and binding scopes, namespaces, and display modifiers, the lookup rules and access boundaries of variables and functions are fundamentally reconstructed, thereby improving code maintainability and security.

Description

Technical Field

[0001] This invention relates to the field of programming language design and implementation technology, and in particular to a method and system for controlling the visibility of programming language scope. Background Technology

[0002] In programming languages, scope and visibility are core mechanisms for controlling code encapsulation, modularity, and security.

[0003] Currently, programming languages ​​primarily rely on static lexical scoping (such as function scoping or block scoping) and class (or module)-based access control modifiers. However, as software systems become increasingly large and complex, especially in scenarios involving microservices, multi-tenancy, and dynamic component loading, traditional scoping models have revealed several limitations. This technical solution addresses the limitations of traditional programming language scoping and visibility control mechanisms.

[0004] To address the aforementioned issues, improvements are needed to the methods for controlling the visibility of programming language scopes. Summary of the Invention

[0005] This invention provides a method and system for controlling the visibility of programming language scopes, in order to solve the problems of unclear program entity access boundaries and inconsistent control rules caused by the lack of a hierarchical control mechanism, resulting in low code maintainability and poor code security.

[0006] In a first aspect, embodiments of the present invention provide a method for controlling the visibility of programming language scopes, including: During the execution of program code, when an execution operation on a program entity is detected, the target scope chain corresponding to the program entity is determined according to the entity type; wherein, the program entity is a variable or a function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one level of scope; According to the hierarchical search rules, the program entity is searched level by level from the current scope of the program code to the last scope of the target scope chain until the program entity is found, and the target scope of the program entity is determined. The program entity is invoked from the namespace corresponding to the target scope.

[0007] Secondly, embodiments of the present invention also provide a visibility control system for programming language scopes, comprising: The scope chain determination module is used to determine the target scope chain corresponding to the program entity based on the entity type when an execution operation on the program entity is detected during the execution of the program code; wherein the program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one level of scope; The scope determination module is used to search for the program entity step by step from the current scope of the program code to the last scope of the target scope chain according to the hierarchical search rules, until the program entity is found, and to determine the target scope where the program entity is located. The program entity invocation module is used to invoke the program entity from the namespace corresponding to the target scope.

[0008] Thirdly, embodiments of the present invention also provide an electronic device, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the visibility control method for programming language scope as described in any embodiment of the present invention.

[0009] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to implement the visibility control method for the programming language scope as described in any embodiment of the present invention when executed.

[0010] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the visibility control method for programming language scope as described in any of the embodiments of the present invention.

[0011] The technical solution of this invention involves determining the target scope chain corresponding to a program entity based on its type during program code execution when an execution operation on a program entity is detected. The program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one hierarchical scope. Following hierarchical search rules, the program entity is searched level by level from the currently accessed scope of the program code to the last level scope of the target scope chain until the program entity is found, thus determining the target scope where the program entity resides. The program entity is then called from the namespace corresponding to the target scope. In this technical solution, by setting hierarchical scopes and binding scopes, namespaces, and display modifiers, the target scope chain corresponding to the program entity is retrieved during program code execution. This allows for the search of the program entity level by level according to pre-set hierarchical search rules corresponding to the hierarchical scopes, until the program entity is found. Then, the program entity is retrieved from the target scope, and operations such as compilation or execution are performed on the program entity. The advantage of this technical solution lies in its introduction of a set of explicit modifiers to construct a multi-level, strictly isolated namespace system with defined access paths. This replaces or enhances the traditional scope model based on lexical nesting and implicit global scope. Each explicit modifier is used when declaring and accessing variables or functions, clearly identifying the lifecycle, accessible scope, and context of a program entity. When a variable is accessed during program code execution, it follows a preset hierarchical scope lookup order, significantly improving the modularity, code clarity, maintainability, and runtime reliability of large software projects. It solves the problems of unclear program entity access boundaries and inconsistent control rules caused by a lack of hierarchical control mechanisms, leading to low code maintainability and poor code security. Through more refined and hierarchical scope settings and the binding of scope, namespace, and explicit modifiers, it fundamentally reconstructs the lookup rules and access boundaries of variables and functions, achieving improved code maintainability and security. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the content of the embodiments of the present invention and these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a method for controlling the visibility of programming language scope according to Embodiment 1 of the present invention; Figure 2This is a flowchart of a method for controlling the visibility of programming language scope according to Embodiment 2 of the present invention; Figure 3 This is a flowchart illustrating an access to a variable according to Embodiment 2 of the present invention; Figure 4 This is a flowchart illustrating a function call according to Embodiment 2 of the present invention; Figure 5 This is a schematic diagram of the structure of a visibility control system for programming language scope provided in Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device that implements the visibility control method for programming language scope according to embodiments of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention. The acquisition, transmission, storage, use, and processing of data in the technical solutions of this application comply with the relevant provisions of national laws and regulations. It should be noted that in the embodiments of this application, certain software, components, or models and other existing solutions in the industry may be mentioned. These should be considered as exemplary, and their purpose is only to illustrate the feasibility of implementing the technical solutions of this application, but it does not mean that the applicant has or necessarily used such solutions.

[0015] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solution disclosed herein all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to maintain user personal information security and network security. It should also be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solution disclosed herein are all conducted with the user's knowledge and consent, and comply with relevant privacy protection regulations.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in sequences other than those illustrated or described herein.

[0017] Before elaborating on this technical solution in detail, let's briefly introduce its application scenarios to help you understand it more clearly.

[0018] This technical solution can be applied to large-scale application software scenarios such as microservices, multi-tenancy, or dynamic component loading. The reason is that this technical solution sets up a hierarchical scope model for each large-scale application software by setting an explicit modifier system. When an actual operation on a program entity is detected, the solution uses the hierarchical lookup rules corresponding to the explicit modifier system to accurately locate the actual scope of the program entity from local to global, thereby improving the maintainability and security of the program code during the execution of large-scale application software.

[0019] In traditional programming languages, scope and visibility are core mechanisms for controlling code encapsulation, modularity, and security. Existing technologies primarily rely on static lexical scoping (such as function scope or block scope) and class (or module)-based access control modifiers (such as public, private, or protected). However, as software systems become increasingly large and complex, especially in scenarios involving microservices, multi-tenancy, and dynamic component loading, traditional scope models reveal several limitations. This technical solution addresses these limitations by introducing a hierarchical namespace system with explicit prefix modifiers. It reconstructs the lookup rules and access boundaries for variables and functions, making it ideal for large and complex software development scenarios, particularly those with high requirements for code encapsulation, modularity, security, and maintainability. Traditional scope models have significant limitations, including: global namespace pollution and implicit coupling, insufficient granularity of scope, overly rigid access control and instance binding, and unclear environment dependency management.

[0020] The aforementioned global namespace pollution and implicit coupling refer to the fact that global variables or functions in traditional programming languages ​​are fully visible throughout the entire program, easily leading to naming conflicts and unpredictable implicit dependencies, reducing code maintainability and reusability. Although modularization technologies (such as Java packages or C++ namespaces) provide some isolation, cross-module access can still produce hidden side effects. The insufficient granularity of scope arises because the scopes of existing models are often nested, with outer variables being visible to inner variables by default. While this facilitates programming, it also makes it difficult to precisely control the lifecycle and scope of influence of variables, especially when using callback functions, closures, or asynchronous code, easily causing logical errors and resource leaks. The overly rigid access control and instance binding refer to the fact that class-based access control in traditional programming languages ​​is usually strongly bound to specific class instances. For static (class-level) shared data or utility functions, the access methods are not consistent with instance members in terms of syntax and semantics. Furthermore, when accessing static resources across classes or modules, the rules are complex and inconsistent, lacking a clear and unified global (non-traditional global) sharing mechanism. The lack of clear environment dependency management refers to the fact that the integration methods of variables (such as environment variables) provided by the system or runtime environment vary in the language. Sometimes they are accessed through special APIs (interfaces), and sometimes they exist as implicit global variables. There is a lack of a standardized, language-built-in scope for unified management, which makes the expression of environment dependencies in the code unclear.

[0021] Based on this, this technical solution introduces a hierarchical namespace system with explicit prefix modifiers on the basis of traditional programming language scope and visibility control methods. This reconstructs the lookup rules and access boundaries of variables and functions, thereby eliminating the abuse of global namespaces, achieving precise explicit control of scope, establishing a unified and hierarchical resource access model, and strengthening static checking and runtime security, so as to improve the development quality and runtime reliability of large software.

[0022] Example 1 Figure 1 The flowchart below illustrates a method for controlling the visibility of programming language scopes according to Embodiment 1 of the present invention. This embodiment is applicable to situations where, during program code execution, variables or functions are accessed or called. Based on a pre-set hierarchical scope, variables or functions are searched level by level according to hierarchical search rules to determine the target scope in which the variable or function resides and then the variable or function is called. This method can be executed by a visibility control system for programming language scopes. This visibility control system for programming language scopes can be implemented in hardware and / or software and can be configured in a computing device capable of executing the visibility control method for programming language scopes.

[0023] like Figure 1As shown, the method includes: S110. During the execution of the program code, when an execution operation on a program entity is detected, the target scope chain corresponding to the program entity is determined according to the entity type.

[0024] In this context, program entities are variables or functions, and the operations performed are variable access operations or function call operations. The target scope chain contains at least one level of scope. If the entity type is a variable, the target scope chain corresponding to the program entity is a variable lookup chain; if the entity type is a function, the target scope chain corresponding to the program entity is a function lookup chain.

[0025] Specifically, during program code execution, determining the current scope of a program entity when an operation on that entity is detected is a fundamental prerequisite for achieving code encapsulation, module isolation, and secure access. Based on this, this technical solution introduces a hierarchical namespace system with explicit prefix modifiers, reconstructing the lookup rules and access boundaries for variables and functions to improve the encapsulation, modularity, security, and maintainability of the program code.

[0026] It should be noted that before executing the program code, at least one level of scope is included, including the current scope, object instance scope, global scope, environment variable scope, and built-in function scope. Each level of scope corresponds to a unique explicit modifier, and during the program code editing phase, the explicit modifier is marked as a prefix identifier of the program entity.

[0027] Among them, the current scope, object instance scope, global scope, environment variable scope, and built-in function scope are pre-set hierarchical scope architectures from local to global. In this technical solution, by setting hierarchical scopes and binding unique explicit modifiers to each level, the scopes can be logically layered according to "local-object instance-global-environment-built-in", and precise control of the access boundaries of program entities can be achieved through explicit representation.

[0028] The advantage of this setup is that it intuitively reflects the scope boundaries of program entities through explicit scope modifiers. At the same time, the hierarchical scope settings not only improve the accuracy of scope division but also avoid global namespace pollution, thereby solving the problems of global namespace pollution and implicit coupling in existing technologies and improving data security and maintainability.

[0029] Optionally, when setting a unique explicit modifier for each scope, this technical solution further includes: for the first explicit modifier corresponding to the current scope, if the program entity is a variable, the prefix identifier of the program entity is an explicit prefix identifier; if the program entity is a function, the prefix identifier of the program entity is an explicit prefix identifier or an implicit prefix identifier; for the second explicit modifier corresponding to the object instance scope, it is used to characterize that the access method for accessing the program entity is limited to access through an object instance, and this access rule strictly follows the object-oriented encapsulation principle; for the third explicit modifier corresponding to the global scope, it is used to characterize that the program entity is a static program entity, and the accessing object can access the program entity across fully qualified names according to the preset access rules, and the access permissions of the program entity are limited; wherein, the preset access rules are explicit import rules and / or entity reference rules; for the fourth explicit modifier corresponding to the environment variable scope, it is used to distinguish between external variables configured at external runtime and internal variables of the program entity; for the fifth explicit modifier corresponding to the built-in function scope, it is used to define the program entity as a program entity that is only visible in the built-in function scope.

[0030] Among them, the first explicit modifier, the second explicit modifier, the third explicit modifier, the fourth explicit modifier, and the fifth explicit modifier are used to identify different scopes and have no actual meaning. The specific settings of each explicit modifier are not limited in this technical solution, and each explicit modifier can be set to the corresponding character according to actual needs.

[0031] For example, the first explicit modifier corresponding to the current scope is set to "c:", the second explicit modifier corresponding to the object instance scope is set to "t:", the third explicit modifier corresponding to the global scope is set to "g:", the fourth explicit modifier corresponding to the environment variable scope is set to "e:", and the fifth explicit modifier corresponding to the built-in function scope is set to "b:".

[0032] Based on this example, a more detailed explanation of each explicit modifier will be provided: (1) The first explicit modifier "c:" indicates that the scope of the program entity is the current scope when the programming language is running. For example, when the program entity is a variable, the variable in the current scope must explicitly use the first explicit modifier "c:". That is, when accessing the variable, the first explicit modifier "c:" must be detected to determine that the scope of the variable is the current scope. When calling a function, even if the first explicit modifier is not recognized, the scope of the function can be assumed to be the current scope.

[0033] (2) The second explicit modifier “t:” is used to indicate that the access method of the access program entity is limited to access through object instances, and this access rule strictly follows the object-oriented encapsulation principle, that is, it identifies the members (fields and methods) of the class. Access must be through object instances, strictly following the object-oriented encapsulation principle, and the second explicit modifier itself conveys the semantics of “instance-related”.

[0034] (3) The third explicit modifier "g:" can replace the traditional "global" concept. g: variables and g: functions are static and can be accessed across fully qualified names (FQNs), but must follow the rules of explicit import or reference. Among them, g: functions cannot access instance members, which guarantees their pure static nature, thus providing a controllable and side-effect-free global sharing mechanism.

[0035] (4) The fourth explicit modifier “e:” is used to identify the scope of environment variables, explicitly incorporating external runtime configurations into the language scope system and clearly separating them from internal program variables.

[0036] (5) The fifth explicit modifier “b:” indicates the scope of built-in functions (if the program entity is a variable, it can also be called the scope of built-in variables). If the fifth explicit modifier “b:” exists before the program entity, it means that the program entity is only visible within the scope of built-in functions, unifying the access interface of system resources.

[0037] Based on this, when an execution operation on a program entity is detected, the current scope of the program entity is determined, including: when an execution operation on a program entity is detected, the current scope of the program entity is determined according to the prefix identifier carried by the program entity.

[0038] Optionally, it also includes: based on the above example, setting at least one controllable access method for program entities in the global scope (i.e., resources in the g: scope), wherein the controllable access method includes explicit fully qualified name reference, alias import, implicit access, and same name nearest access.

[0039] The purpose of this setup is to allow for precise and unambiguous access via the fully qualified name (FQN) format `@variable.galore-name`. Alias ​​imports create short aliases for Galore resources using the `import galore alias fqn` statement, improving code conciseness while ensuring local variables do not conflict with the alias, thus maintaining a clean namespace. Implicit access allows direct use of variable names (unambiguously) after importing the Galore namespace, providing convenience in functional programming. The "nearest access" method applies the "nearest" principle and generates compiler warnings when multiple sources pointed to by an alias contain resources with the same name, guiding developers to explicitly depend on them.

[0040] Optionally, it also includes: for the fifth explicit modifier corresponding to the scope of the built-in function, the fifth explicit modifier is deeply bound to a keyword in a specific code block in the programming language of the program entity being edited.

[0041] The specific code block includes at least one of the following: asynchronous code block, transaction code block, or code block whose features specify functionality.

[0042] Building upon the examples above, the fifth explicit modifier "b:" is deeply integrated with the keyword `neta` in the language (e.g., referring to asynchronous operations, transactions, or specific code block structures). Optionally, if the target scope of the program entity is a built-in function scope, the program entity is only visible within that built-in function scope. For example, a `b:` variable defined within a `neta` block is absolutely invisible outside the block, perfectly suited for scenarios requiring strict isolation of temporary states, such as asynchronous tasks and transaction processing.

[0043] Based on this, this technical solution establishes a hierarchical scope setting and binds a unique explicit modifier to each level. By introducing such a structured modifier system, and in conjunction with hierarchical scope lookup rules and strict compile-time checks, a highly explicit, finely controlled, hierarchical, and secure scope and visibility model is constructed. This not only effectively solves problems such as traditional global variable pollution or scope leakage, but also provides native, language-level support for programming languages ​​through the innovative design of the built-in function scope "b:", significantly improving the maintainability, readability, and runtime security of complex software systems.

[0044] For example, if the program entity is a variable, the variable lookup chain can be set as "c: (current scope) → t: (object instance scope) → g: (global scope) → e: (environment variable scope) → b: (built-in function scope)". By setting the variable lookup chain, it can be ensured that during the execution of the program code, when a variable access operation is detected, the variable is searched step-by-step from the current scope to the built-in function scope, achieving an ordered search from the most local to the most systematic.

[0045] For example, if the program entity is a function, the function lookup chain can be set as follows: "ordinary function (current scope) → t: member function (object instance scope) → g: Galore function (global scope) → b: built-in function (built-in function scope)". By setting up the function lookup chain, it is possible to clearly distinguish between function implementations, object behaviors, global tools, and system functions. This hierarchical scope setting avoids lookup ambiguities during function calls, making access costs predictable.

[0046] S120. According to the hierarchical search rules, search for the program entity level by level from the current scope of the program code to the last scope of the target scope chain until the program entity is found, and determine the target scope where the program entity is located.

[0047] The hierarchical search rule refers to the rule of searching from the current scope of the program entity to a larger scope level by level. The last-level scope refers to the last scope in the target scope chain; for example, in this technical solution, the last-level scope is the scope of built-in functions. The target scope refers to the actual scope where the program entity resides; for example, it can be the current scope accessed by the program code, the last scope in the target scope chain, or any other level of scope.

[0048] Specifically, following the hierarchical search rules, the search scope of the program entity is expanded level by level. The scope of each level is traversed from the current scope until the program entity is found. The scope where the program entity is located at this time is taken as the target scope.

[0049] S130. Call the program entity from the namespace corresponding to the target scope.

[0050] A namespace is a set of identifiers that logically group program entities. While a scope defines the visibility and lifecycle of a program entity, a namespace provides a unique, explicit access path and boundary identifier for different scopes.

[0051] Building upon the example above, during program code execution, after determining the target scope of a program entity, the entity must be called from the namespace corresponding to that target scope. This is because the hierarchical namespaces in this technical solution are dedicated spaces for each scope. Binding the scope, namespace, and explicit modifiers defines a compliant access path for the program entity. Calling the entity outside its namespace would break the hierarchical isolation rules of this solution, leading to issues such as global namespace pollution, implicit coupling, and out-of-bounds access. Therefore, calling the program entity from the namespace corresponding to the target scope effectively avoids out-of-bounds calls, and subsequent data tracing can be performed based on the defined access path, improving the security and maintainability of the program code.

[0052] The technical solution of this invention, during the execution of program code, when an execution operation on a program entity is detected, determines the target scope chain corresponding to the program entity based on the entity type; wherein the program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one hierarchical scope; according to the hierarchical search rules, the program entity is searched level by level from the currently accessed scope of the program code to the last level scope of the target scope chain until the program entity is found, thus determining the target scope where the program entity is located; the program entity is then called from the namespace corresponding to the target scope. In this technical solution, by setting hierarchical scopes and binding scopes, namespaces, and display modifiers, the target scope chain corresponding to the program entity is retrieved during the execution of the program code, thereby searching for the program entity level by level in each level scope according to the pre-set hierarchical search rules corresponding to the hierarchical scopes until the program entity is found, and then the program entity is retrieved from the target scope and compiled or run. The advantage of this technical solution lies in its introduction of a set of explicit modifiers to construct a multi-level, strictly isolated namespace system with defined access paths. This replaces or enhances the traditional scope model based on lexical nesting and implicit global scope. Each explicit modifier is used when declaring and accessing variables or functions, clearly identifying the lifecycle, accessible scope, and context of a program entity. When a variable is accessed during program code execution, it follows a preset hierarchical scope lookup order, significantly improving the modularity, code clarity, maintainability, and runtime reliability of large software projects. It solves the problems of unclear program entity access boundaries and inconsistent control rules caused by a lack of hierarchical control mechanisms, leading to low code maintainability and poor code security. Through more refined and hierarchical scope settings and the binding of scope, namespace, and explicit modifiers, it fundamentally reconstructs the lookup rules and access boundaries of variables and functions, achieving improved code maintainability and security.

[0053] Example 2 Figure 2 The flowchart illustrates a method for controlling the visibility of programming language scopes according to Embodiment 2 of the present invention. Optionally, for entities of variable or function type, the target scope chain corresponding to the program entity is refined based on the entity type.

[0054] like Figure 2 As shown, the method includes: S210. During the execution of the program code, when an execution operation on a program entity is detected, the target scope chain corresponding to the program entity is determined according to the entity type.

[0055] S220. If the entity type is a variable type, then execute S230. If the entity type is a function type, then execute S240.

[0056] S230, retrieve the pre-set variable lookup chain as the target scope chain of the program entity.

[0057] S240. Retrieve the pre-set function lookup chain as the target scope chain of the program entity.

[0058] S250. According to the hierarchical search rules, search for the program entity level by level from the current scope of the program code to the last scope of the target scope chain until the program entity is found, and determine the target scope where the program entity is located.

[0059] For example, Phoenix is ​​a language that integrates object-oriented and functional programming. Taking a program implemented in Phoenix as an example, if the program entity is a variable, then the target scope chain is a variable lookup chain. Figure 3 As shown, during the execution of the program code, when it detects that the program code is attempting to access a variable, it first searches within the current scope of the accessed program code using the current namespace identifier "c:". If the target variable (i.e., the program entity) is not found in the current scope, the system will automatically switch to the member variable scope (i.e., the instance object scope) for a second search. The member variable scope is accessed through the type-qualified namespace "t:" of the instantiated object. If the member variable scope search fails, it enters the global class variable scope (i.e., the global scope), which is managed using the global qualified namespace "g:". If the target variable is still not found, the system will further search the environment variable scope, which uses the environment namespace identifier "e:". Finally, the system will perform a final search in the built-in variable namespace scope (i.e., the built-in function scope), which uses the fifth display modifier "b:".

[0060] Understandably, Phoenix has a compilation process. For some explicitly defined variables, errors that detect the non-existence of variables will be detected and exceptions will be thrown during the compilation phase. For other variables, values ​​are assigned during runtime, and such errors will be caught and handled at runtime.

[0061] For example, continuing with the Phoenix language implementation, if the program entity is a function, then the target scope chain is the function lookup chain. For example... Figure 4As shown, when program code initiates a call to the target function (i.e., the program entity), it first attempts to resolve the function within the ordinary function scope (i.e., the current scope). Functions in this ordinary scope are private and can only be accessed in the file where they are defined. If resolution fails in the ordinary function scope, the system switches to the member function scope (i.e., the instance object scope), which is accessed through the type-qualified namespace "t:". If resolution fails in the member function scope, it enters the Galore scope (i.e., the global scope), which is a global class function scope managed by the global qualified namespace "g:". If resolution still fails, the system finally resolves the function in the Built-in scope (i.e., the built-in function scope), which uses the fifth display modifier "b:". If the target function fails to resolve in all the aforementioned scopes, the system throws a runtime exception indicating that the target function is undefined or inaccessible. Conversely, if resolution succeeds at any stage, the target function is immediately called and executed.

[0062] The advantage of this technical solution lies in its ability to construct a multi-layered, strictly isolated namespace system with defined access paths by introducing a set of explicit modifiers, thereby replacing or enhancing the traditional scope model based on lexical nesting and implicit global scope. The core of the system is the definition of five key scope modifiers: c: (current scope), t: (instance object scope), g: (Galore, i.e., controllable global scope), e: (environment variable scope), and b: (built-in function scope). Each explicit modifier is used when declaring and accessing variables or functions, clearly identifying the lifecycle, accessible scope, and context of a program entity.

[0063] Specifically, when a variable is accessed during program code execution, a predefined hierarchical scope lookup order is followed. First, the variable is searched in the current scope (c). If the search fails, it is searched in the object instance scope (t). If that fails, it is searched in the global scope (g). If that fails, it is searched in the environment variable scope (e). Finally, it is searched in the built-in function scope (b). This process ensures the determinism and efficiency of variable lookup during access. For function calls, the lookup order is similar, starting with private functions and sequentially searching through member functions (t), global static functions (g), and built-in functions (b). This significantly improves the modularity, code clarity, maintainability, and runtime reliability of large software projects.

[0064] S260. Call the program entity from the namespace corresponding to the target scope.

[0065] It should be noted that, in this technical solution, after calling the program entity, the following steps are also included: performing compilation processing on the program code containing the program entity based on pre-set compilation detection rules to obtain the compilation result; wherein, the compilation detection rules include at least one of the following language constraints: a. Functions carrying instance identifiers are prohibited from being defined outside the class scope; b. Variables with instance identifiers or non-static functions are prohibited within functions with global identifiers; c. When importing non-fully qualified class names, force the use of the fully qualified keyword; d. Validate for conflicts between local variables and global aliases; e. If a class contains members that carry instance identifiers, then other members that are not explicitly marked will be automatically made inaccessible.

[0066] For example, this technical solution includes a series of mandatory compile-time checks during the compilation phase of the program code, thus solidifying the design intent into language constraints: a. It is forbidden to define the t: function in a non-class scope.

[0067] b. Prohibit the use of t: variables or non-static functions within g: functions, and force them to be statically pure.

[0068] c. When importing non-FQN classes, the `galore` keyword must be used to prevent misuse.

[0069] d. Check for conflicts between local variables and the Galore alias.

[0070] e. Once a class has a t: member, other members that are not explicitly marked automatically become inaccessible (private), reinforcing the "explicit disclosure" principle.

[0071] Specifically, variables defined with the `c:` explicit modifier are completely invisible outside the exact code block in which they are defined (such as a function body or a `neta` block), and are inaccessible even in nested sub-scopes. This provides strong protection for scenarios requiring strict isolation of temporary data. The `g:` scope, on the other hand, achieves cross-module sharing through explicit import mechanisms, avoiding the pollution of traditional global namespaces. Furthermore, `g:` functions are restricted to pure static and cannot access instance state.

[0072] The technical solution of this invention, during the execution of program code, when an execution operation on a program entity is detected, determines the target scope chain corresponding to the program entity based on the entity type; wherein the program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one hierarchical scope; according to the hierarchical search rules, the program entity is searched level by level from the current scope accessed by the program code to the last level scope of the target scope chain until the program entity is found, thus determining the target scope where the program entity is located; the program entity is then called from the namespace corresponding to the target scope. In this technical solution, by setting hierarchical scopes and binding scopes, namespaces, and display modifiers, the target scope chain corresponding to the program entity is retrieved during the execution of program code, thereby searching for the program entity level by level in each level scope according to the pre-set hierarchical search rules corresponding to the hierarchical scopes, until the program entity is found, and then the program entity is retrieved from the target scope, and operations such as compilation or execution are performed on the program entity. The advantage of this technical solution lies in its introduction of a set of explicit modifiers to construct a multi-level, strictly isolated namespace system with defined access paths. This replaces or enhances the traditional scope model based on lexical nesting and implicit global scope. Each explicit modifier is used when declaring and accessing variables or functions, clearly identifying the lifecycle, accessible scope, and context of a program entity. When a variable is accessed during program code execution, it follows a preset hierarchical scope lookup order, significantly improving the modularity, code clarity, maintainability, and runtime reliability of large software projects. It solves the problems of unclear program entity access boundaries and inconsistent control rules caused by a lack of hierarchical control mechanisms, leading to low code maintainability and poor code security. Through more refined and hierarchical scope settings and the binding of scope, namespace, and explicit modifiers, it fundamentally reconstructs the lookup rules and access boundaries of variables and functions, achieving improved code maintainability and security.

[0073] Example 3 Figure 5 This is a schematic diagram of a visibility control system for programming language scopes provided in Embodiment 3 of the present invention. Figure 5 As shown, the system includes: a scope chain determination module 310, a scope determination module 320, and a program entity invocation module 330.

[0074] The scope chain determination module 310 is used to determine the target scope chain corresponding to the program entity based on the entity type when an execution operation on the program entity is detected during the execution of the program code; wherein the program entity is a variable or a function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one level of scope. The scope determination module 320 is used to search for the program entity step by step from the scope currently accessed by the program code to the last scope of the target scope chain according to the hierarchical search rules, until the program entity is found, and to determine the target scope where the program entity is located. The program entity invocation module 330 is used to invoke the program entity from the namespace corresponding to the target scope.

[0075] The technical solution of this invention involves determining the target scope chain corresponding to a program entity based on its type during program code execution when an execution operation on a program entity is detected. The program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one hierarchical scope. Following hierarchical search rules, the program entity is searched level by level from the currently accessed scope of the program code to the last level scope of the target scope chain until the program entity is found, thus determining the target scope where the program entity resides. The program entity is then called from the namespace corresponding to the target scope. In this technical solution, by setting hierarchical scopes and binding scopes, namespaces, and display modifiers, the target scope chain corresponding to the program entity is retrieved during program code execution. This allows for the search of the program entity level by level according to pre-set hierarchical search rules corresponding to the hierarchical scopes, until the program entity is found. Then, the program entity is retrieved from the target scope, and operations such as compilation or execution are performed on the program entity. The advantage of this technical solution lies in its introduction of a set of explicit modifiers to construct a multi-level, strictly isolated namespace system with defined access paths. This replaces or enhances the traditional scope model based on lexical nesting and implicit global scope. Each explicit modifier is used when declaring and accessing variables or functions, clearly identifying the lifecycle, accessible scope, and context of a program entity. When a variable is accessed during program code execution, it follows a preset hierarchical scope lookup order, significantly improving the modularity, code clarity, maintainability, and runtime reliability of large software projects. It solves the problems of unclear program entity access boundaries and inconsistent control rules caused by a lack of hierarchical control mechanisms, leading to low code maintainability and poor code security. Through more refined and hierarchical scope settings and the binding of scope, namespace, and explicit modifiers, it fundamentally reconstructs the lookup rules and access boundaries of variables and functions, achieving improved code maintainability and security.

[0076] Optionally, the visibility control system for programming language scopes includes at least one hierarchical scope including the current scope, object instance scope, global scope, environment variable scope, and built-in function scope. Each hierarchical scope corresponds to a unique explicit modifier, and during the program code editing phase, the explicit modifier is marked as a prefix identifier for the program entity.

[0077] Optionally, an identifier detection module is used to determine the current scope of a program entity based on the prefix identifier carried by the program entity when an operation on the program entity is detected.

[0078] Optionally, the visibility control system for programming language scope includes: for the first explicit modifier corresponding to the current scope, if the program entity is a variable, the prefix identifier of the program entity is an explicit prefix identifier; if the program entity is a function, the prefix identifier of the program entity is either an explicit prefix identifier or an implicit prefix identifier. For the second explicit modifier corresponding to the scope of the object instance, it is used to indicate that the access method of accessing the program entity is limited to access through the object instance, and this access rule strictly follows the encapsulation principle of object-oriented programming. The third explicit modifier corresponding to the global scope is used to indicate that the program entity is a static program entity, and the access object can access the program entity across fully qualified names according to the preset access rules, and restrict the access permissions of the program entity; wherein, the preset access rules are explicit import rules and / or entity reference rules; The fourth explicit modifier corresponding to the scope of environment variables is used to distinguish between external variables configured at the external runtime and internal variables of the program entity; The fifth explicit modifier corresponding to the scope of built-in functions is used to define a program entity as a program entity that is only visible in the scope of built-in functions.

[0079] Optionally, the visibility control system for programming language scope is also used for program entities in the global scope, where the program entities include at least one controllable access method; wherein, the controllable access method includes explicit fully qualified name reference, alias import, implicit access, and access by name.

[0080] Optionally, the visibility control system for programming language scope is also used for the fifth explicit modifier corresponding to the scope of a built-in function, wherein the fifth explicit modifier is deeply bound to a keyword in a specific code block in the programming language that edits the program entity; wherein the specific code block includes at least one of an asynchronous code block, a transaction code block, or a code block whose features specify functionality.

[0081] Optionally, the visibility control system for programming language scope is further configured to ensure that if the target scope corresponding to the program entity is the scope of the built-in function, then the program entity is only visible within the scope of the built-in function.

[0082] Optionally, the target scope chain determination module includes: a first unit, used to retrieve a pre-set variable lookup chain as the target scope chain of the program entity if the entity type is a variable type; The second unit is used to retrieve a pre-set function lookup chain as the target scope chain of the program entity if the entity type is a function type.

[0083] Optionally, the visibility control system for programming language scope is also used to perform compilation processing on the program code containing the program entity based on pre-set compilation detection rules after the program entity is called, so as to obtain the compilation result; The compilation detection rules include at least one of the following language constraints: a. Functions carrying instance identifiers are prohibited from being defined outside the class scope; b. Variables with instance identifiers or non-static functions are prohibited within functions with global identifiers; b. When importing non-fully qualified class names, force the use of the fully qualified keyword; d. Validate for conflicts between local variables and global aliases; e. If a class contains members that carry instance identifiers, then other members that are not explicitly marked will be automatically made inaccessible.

[0084] The visibility control system for programming language scopes provided in this embodiment of the invention can execute the visibility control method for programming language scopes provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0085] Example 4 Figure 6 A schematic diagram of an electronic device 10 according to an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile systems, such as personal digital processing units, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing systems. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0086] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0087] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0088] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as visibility control methods for programming language scopes.

[0089] In some embodiments, the visibility control method for programming language scopes may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the visibility control method for programming language scopes described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the visibility control method for programming language scopes by any other suitable means (e.g., by means of firmware).

[0090] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input system, and at least one output system, and transferring data and instructions to the storage system, the at least one input system, and the at least one output system.

[0091] Computer programs for implementing the visibility control method of programming language scope of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0092] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, system, or device. A computer-readable storage medium can be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0093] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display system (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing system (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of systems can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0094] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0095] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0096] Example 5 This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the visibility control method for programming language scope as provided in any embodiment of this application.

[0097] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0099] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for controlling the visibility of a programming language scope, characterized in that, include: During the execution of program code, when an execution operation on a program entity is detected, the target scope chain corresponding to the program entity is determined according to the entity type; wherein, the program entity is a variable or a function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one level of scope; According to the hierarchical search rules, the program entity is searched level by level from the current scope of the program code to the last scope of the target scope chain until the program entity is found, and the target scope of the program entity is determined. The program entity is invoked from the namespace corresponding to the target scope.

2. The method according to claim 1, characterized in that, include: At least one of the aforementioned hierarchical scopes includes the current scope, object instance scope, global scope, environment variable scope, and built-in function scope. Each hierarchical scope corresponds to a unique explicit modifier, and during the editing phase of the program code, the explicit modifier is marked as a prefix identifier of the program entity.

3. The method according to claim 2, characterized in that, When an execution operation on a program entity is detected, determining the current scope of the program entity includes: When an operation is detected to be performed on the program entity, the scope corresponding to the program entity is determined based on the prefix identifier carried by the program entity.

4. The method according to claim 3, characterized in that, include: For the first explicit modifier corresponding to the current scope, if the program entity is a variable, then the prefix identifier of the program entity is an explicit prefix identifier; if the program entity is a function, then the prefix identifier of the program entity is either an explicit prefix identifier or an implicit prefix identifier. The second explicit modifier corresponding to the scope of the object instance is used to indicate that the access method for accessing the program entity is limited to access through the object instance, and this access rule strictly follows the encapsulation principle of object-oriented programming. The third explicit modifier corresponding to the global scope is used to characterize the program entity as a static program entity, and the access object can access the program entity across fully qualified names according to the preset access rules, and limit the access permissions of the program entity; wherein, the preset access rules are explicit import rules and / or entity reference rules; The fourth explicit modifier corresponding to the scope of the environment variable is used to distinguish between external variables configured at the external runtime and internal variables of the program entity. The fifth explicit modifier corresponding to the scope of the built-in function is used to define the program entity as a program entity that is only visible in the scope of the built-in function.

5. The method according to claim 2, characterized in that, Also includes: For program entities in the global scope, the program entities include at least one controllable access method; wherein, the controllable access method includes explicit fully qualified name reference method, alias import method, implicit access method, and same name nearest access method.

6. The method according to claim 2, characterized in that, Also includes: For the fifth explicit modifier corresponding to the scope of the built-in function, the fifth explicit modifier is deeply bound to a keyword in a specific code block in the programming language that edits the program entity; wherein, the specific code block includes at least one of an asynchronous code block, a transaction code block, or a code block whose features specify functionality.

7. The method according to claim 6, characterized in that, Also includes: If the target scope corresponding to the program entity is the scope of the built-in function, then the program entity is only visible within the scope of the built-in function.

8. The method according to claim 1, characterized in that, The entity type is a variable type or a function type, and the step of determining the target scope chain corresponding to the program entity based on the entity type includes: If the entity type is the variable type, then the pre-set variable lookup chain is retrieved as the target scope chain of the program entity; If the entity type is the function type, then the pre-set function lookup chain is retrieved as the target scope chain of the program entity.

9. The method according to claim 1, characterized in that, Also includes: After the program entity is invoked, the program code containing the program entity is processed for compilation based on pre-set compilation detection rules to obtain the compilation result; The compilation detection rules include at least one of the following language constraints: a. Functions carrying instance identifiers are prohibited from being defined outside the class scope; b. Variables with instance identifiers or non-static functions are prohibited within functions with global identifiers; b. When importing non-fully qualified class names, force the use of the fully qualified keyword; d. Validate for conflicts between local variables and global aliases; e. If a class contains members that carry instance identifiers, then other members that are not explicitly marked will be automatically made inaccessible.

10. A visibility control system for programming language scopes, characterized in that, include: The scope chain determination module is used to determine the target scope chain corresponding to the program entity based on the entity type when an execution operation on the program entity is detected during the execution of the program code; wherein the program entity is a variable or function, the execution operation is a variable access operation or a function call operation, and the target scope chain contains at least one level of scope; The scope determination module is used to search for the program entity step by step from the current scope of the program code to the last scope of the target scope chain according to the hierarchical search rules, until the program entity is found, and to determine the target scope where the program entity is located. The program entity invocation module is used to invoke the program entity from the namespace corresponding to the target scope.

Images