Method and device for realizing cross-programming language function call and medium

Abstract

The invention discloses a cross-programming language function call implementation method and device and a medium. The method comprises the steps that a function call request is sent to a webpage side; obtaining an execution result of the webpage end; and converting the object identifier in the execution result into a local object according to a preset function library, converting the target format data into a local data type to obtain a conversion result, and feeding back the conversion result to a local calling party. According to the cross-programming language function call implementation method and device and the medium, by unifying call parameters and interface definitions, positioning and executing functions by means of a preset object or a class matching mechanism, and converting result data by means of a preset function library, a cross-language function call link is opened in the whole process, and the cross-programming language function call efficiency is improved. The workload of adaptive development and compatibility testing is reduced, and the problem that the development and testing cost is high due to the fact that function-level cross-language calling between a local program developed by different programming languages and a network end program is difficult to achieve can be solved.

Description

Technical Field

[0001] This invention relates to the field of cross-programming language interaction technology, and in particular to a method, apparatus and medium for implementing cross-programming language function calls. Background Technology

[0002] In the current software architecture, local programs and web-based systems often employ different technology stacks due to varying scenario requirements. Desktop applications typically use languages ​​like C# and C++ to develop high-performance modules, while web applications primarily use languages ​​like TypeScript and Java adapted to browser environments. With system iterations, the need for integrating old and new modules and reusing functions across teams becomes frequent, but different languages ​​have inherent differences in syntax, logic, and data types. Existing technologies offer multiple implementation paths for inter-program interaction requirements developed in different programming languages. JNI technology can be used to write code for cross-language calls; application-level interaction mechanisms can be built using remote protocols like HTTP; furthermore, when adapting to a new programming language, existing functional modules can be rewritten to ensure compatibility with systems developed in the new language, thus supporting system integration or function reuse scenarios.

[0003] However, using JNI technology to achieve cross-language calls requires writing a large amount of glue code, which not only significantly increases development complexity but also leads to high runtime performance overhead. Interaction mechanisms built on remote protocols such as HTTP can only achieve application-level data transmission and interaction, which cannot meet the needs of precise function-level calls and is difficult to support fine-grained functional collaboration. On the other hand, rewriting functions to adapt to new programming languages ​​requires a high investment in development and testing costs, especially for legacy systems, and also faces compatibility risks. The overall resource investment is large and the implementation is difficult. Therefore, existing technologies have obvious shortcomings in achieving interaction between programs in different programming languages. Summary of the Invention

[0004] This invention provides a method, apparatus, and medium for implementing cross-programming language function calls, in order to solve the problem of high development and testing costs caused by the difficulty in implementing cross-language function calls between local programs developed in different programming languages ​​and network programs.

[0005] To achieve the above objectives, this application provides a method for implementing cross-programming language function calls, applicable to local interactive terminals, including: Send a function call request to the web page; wherein the call parameters corresponding to the function call request are consistent with the interface definition of the function in the programming language used by the web page; Obtain the execution result from the webpage; wherein the execution result is generated by the webpage after locating the target object or target class and executing the corresponding function based on the sent function call request through a preset object matching mechanism or class matching mechanism; The object identifier in the execution result is converted into a local object according to the preset function library, and the target format data is converted into a local data type to obtain the conversion result, and the conversion result is fed back to the local caller.

[0006] This invention ensures that function call parameters are consistent with the web interface definition, eliminating adaptation barriers caused by differences in parameter formats and naming rules between different programming languages. It also reduces the workload for developers to write additional conversion logic to adapt to multi-language parameters, thus lowering development complexity caused by parameter incompatibility at the source. Utilizing a pre-defined object or class matching mechanism, the web interface can accurately locate and execute the target function across differences in object models and class inheritance hierarchies between different programming languages, avoiding function call failures or erroneous executions due to language differences and reducing the cost of repeated debugging during testing due to call location issues. Furthermore, a pre-defined function library completes the conversion from object identifiers to local objects and from target format data to local data types, solving cross-language data compatibility problems. This series of designs, from call request and function execution to result feedback, establishes a seamless cross-language interaction link between the local program and the web program, avoiding extensive adaptation development and frequent compatibility debugging during testing. This effectively solves the problems of difficult implementation and high development and testing costs associated with traditional cross-language function calls.

[0007] Compared to existing technologies, this invention establishes a seamless cross-language function call chain by unifying call parameters and interface definitions, locating and executing functions using a preset object or class matching mechanism, and converting result data based on a preset function library. This reduces the workload of adaptation development and compatibility testing, thus solving the problem of high development and testing costs caused by the difficulty in achieving function-level cross-language calls between local programs developed in different programming languages ​​and network programs.

[0008] As a preferred embodiment, the preset function library includes a connection module, an interaction module, and a conversion module; The connection module is used to establish a connection between the local interactive terminal and the web page terminal through middleware; The interaction module is used to send function call requests to the web page through a preset protocol and to obtain the corresponding execution results; The conversion module is used to convert the object ID in the execution result into the object corresponding to the local interactive terminal, convert the result string into an array, and convert the result string into a number.

[0009] This preferred solution provides structured support for cross-programming language function calls by clearly defining the roles of three modules: connection, interaction, and conversion within the pre-defined function library. The connection module establishes the communication foundation between the local interactive client and the web client using middleware, ensuring stable and reliable cross-platform connections. The interaction module standardizes the request sending and result retrieval process through a pre-defined protocol, reducing call failures caused by inconsistent communication formats. The conversion module specifically addresses the mapping between object identifiers and local objects, as well as data type conversion issues, avoiding object reference invalidation or data parsing errors due to language differences. The three modules work synergistically, ensuring the orderly execution of each stage of cross-language calls, improving the accuracy and efficiency of calls, and lowering the technical barrier to cross-platform interaction.

[0010] As a preferred embodiment, the local interactive terminal and the web terminal are connected based on the connection module of the preset function library, specifically as follows: The web page sends a local program call request to the designated port of the middleware; After receiving the local program call request, the middleware allocates an available port and synchronizes it to the local interactive terminal and the web page terminal. The local interactive terminal receives the available port, starts a listening service based on the available port, and establishes a communication connection with the web page after initiating a connection request on the web page.

[0011] This preferred solution refines the connection establishment process between the local interactive client and the web client. By dynamically allocating available ports through middleware, it effectively avoids conflicts that may be caused by fixed ports, enhancing the flexibility and stability of cross-platform communication. After the web client initiates a request, the middleware synchronizes port information to both ends, ensuring that the local interactive client accurately starts the listening service, making the connection establishment process traceable and controllable. This dynamic port allocation mechanism is particularly suitable for concurrent call requirements in multiple scenarios. It can adapt to complex network environments and simplify the tedious port configuration operations during development, significantly improving the reliability and adaptability of cross-platform connections.

[0012] As a preferred solution, the function call request is sent to the web page, specifically as follows: If the function call request is an attribute operation, then the target object identifier, target attribute name and operation type identifier are added to the function call request based on the preset function library to obtain the processed function call request; The processed function call request is sent to the web page based on the target port using a preset protocol.

[0013] This preferred solution, for function call requests involving attribute operations, explicitly defines the processing logic for adding target object identifiers, attribute names, and operation type identifiers, ensuring that the request information is complete and unambiguous. By sending the processed request through a preset protocol and target port, the web interface can quickly identify the operation object, attribute, and specific operation type, avoiding attribute operation errors caused by missing information. This standardized request format design unifies the standard for cross-language attribute interaction, reduces misunderstandings caused by language differences, and improves the accuracy and response efficiency of attribute operation function calls.

[0014] As a preferred embodiment, the calling parameters corresponding to the function call request are consistent with the interface definition of the programming language function used on the web page, specifically: The function name, parameter type, and return value type corresponding to the function call request are consistent with the function name, parameter type, and return value type of the programming language function used on the web page.

[0015] This preferred solution requires that the function name, parameter types, and return value type of the function call request be consistent with the function interface definition on the web page, fundamentally solving the core problem of interface mismatch in cross-language calls. A unified interface definition ensures that requests from the local interactive end can be accurately identified and parsed by the web page, avoiding call failures caused by function name confusion, incompatible parameter types, or incorrect return value formats, significantly reducing debugging costs. At the same time, standardized interface specifications make it easier for developers to understand the cross-platform function call logic, reducing the learning cost of cross-language development and improving overall development efficiency and system compatibility.

[0016] As a preferred solution, the object identifier in the execution result is converted into a local object according to a preset function library, specifically as follows: If the object identifier in the execution result is the identifier of the newly created object on the web page, then based on the object identifier, a local shell object that is consistent with the object structure definition on the web page is created on the local interactive terminal to obtain the transformed local object; If the object identifier in the execution result is an identifier of an object that already exists on the web page, then the corresponding shell object that has been associated and stored in the preset function library is retrieved to obtain the transformed local object; wherein, the preset function library includes an association mapping between web page object identifiers and local shell objects, and the association mapping is established based on the interaction process of historically received object identifiers and historically created shell objects.

[0017] This preferred solution effectively solves the consistency problem of object references in cross-language environments by differentiating the identification conversion logic between newly created objects and existing objects. For new objects, a local shell object with a consistent structure is created to ensure that the local interactive end can accurately map the attributes and behaviors of the web-side object. For existing objects, historical shell objects are retrieved through association mapping to avoid resource waste caused by repeated creation, while ensuring the synchronization of object states. The association mapping mechanism in the preset function library establishes a correspondence between object identifiers and local shells based on historical interactions, ensuring the continuity and accuracy of cross-platform object interactions and improving the reliability of cross-language calls for complex objects.

[0018] As a preferred embodiment, the object matching mechanism is implemented based on the mapping relationship in the ID object manager, and the ID object manager is obtained in the following way: All classes in the web page that need to be associated with the local interactive terminal inherit from the same preset base class, and a unique object identifier is generated based on the preset base class. Using the unique object identifier as the key and the object created on the webpage as the value, insert it into the global mapping table of the initial id object manager to obtain the id object manager with object matching capability.

[0019] The proposed object matching mechanism in this preferred solution is based on an ID object manager. It uses a predefined base class to uniformly manage the classes that need to be associated on the webpage, ensuring that each object generates a unique identifier and resolving the issue of ambiguous object location in cross-language calls. The mapping relationship, with the unique object identifier as the key and the object as the value, allows the webpage to quickly locate the target object based on the function call request, avoiding matching errors caused by duplicate object names or confused identifiers. The inheritance requirement of the predefined base class unifies object management standards, simplifies the maintenance process of the mapping table, significantly improves the efficiency and accuracy of object matching, and provides fundamental support for the rapid execution of cross-language function calls.

[0020] As a preferred embodiment, the class matching mechanism is implemented based on the mapping relationship in the class manager, and the specific method for obtaining the class manager is as follows: For all classes in the web page that need to be associated with the local interactive terminal and have static method call requirements or instantiation requirements, add a preset decorator to the class name; The decorator calls the corresponding manager method, using the class name as the key and the class corresponding to the class name as the value, to insert the class manager into the global mapping table of the initial class manager, thereby obtaining the class manager with class matching capability.

[0021] This preferred solution's class matching mechanism uses a class manager to automatically register classes that require static method calls or are newly created, employing preset decorators to simplify the preparation work for cross-language class-level calls. The manager method triggered by the decorator establishes a mapping relationship using the class name as the key, allowing the web interface to quickly locate the target class directly by its name, satisfying both static method call and dynamic creation requirements. This design avoids the tedious operation of manually registering classes, reduces human error, and ensures efficient class matching, improving the response speed and development convenience of cross-language class-level calls.

[0022] As a preferred embodiment, the function call request includes a target identifier, a function name, and a list of function parameters.

[0023] This preferred solution explicitly requires function call requests to include a target identifier, function name, and parameter list, providing standardized elements for parsing cross-language requests. The target identifier accurately locates the calling object or class, the function name clearly defines the operation target, and the parameter list ensures the completeness of the call parameters. The combination of these three elements allows the web interface to quickly understand the call intent, avoiding parsing errors caused by missing information. This structured request design unifies the information transmission standards for cross-language calls, improves the efficiency and accuracy of request parsing, reduces call failures caused by formatting issues, and ensures smooth execution of cross-programming language function calls.

[0024] This application also provides an implementation device for cross-programming language function calls, suitable for local interactive terminals, including a request module, an execution module, and a feedback module; The request module is used to send a function call request to the web page; wherein the call parameters corresponding to the function call request are consistent with the interface definition of the function in the programming language used by the web page. The execution module is used to obtain the execution result from the web page; wherein, the execution result is generated by the web page after locating the target object or target class and executing the corresponding function based on the function call request sent, through a preset object matching mechanism or class matching mechanism. The feedback module is used to convert the object identifier in the execution result into a local object and the target format data into a local data type according to a preset function library, to obtain the conversion result, and to feed the conversion result back to the local caller.

[0025] This application also provides a storage medium storing a computer program, which is called and executed by a computer to implement the method for cross-programming language function calls as described above.

[0026] This application also provides a computer program product, including a computer program or instructions, which, when executed by a communication device, implements the method for cross-programming language function calls as described above. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a method for implementing cross-programming language function calls according to an embodiment of this application; Figure 2 This is a diagram illustrating the connection establishment and communication process provided in an embodiment of this application; Figure 3 This is a diagram of the function call mechanism provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an implementation device for cross-programming language function calls provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" and "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "several" means two or more.

[0030] The implementation method of cross-programming language function calls provided in this application aims to solve the common problem of cross-language function integration between Web and traditional C# desktop systems in the prior art: when a Web system needs to integrate the functions of a C# desktop product developed by a third party or other team, it is often necessary to ask the C# function provider to rewrite the functions based on the TypeScript language commonly used by the Web. This not only generates extremely high development and testing costs, but also leads to a significant extension of the function integration cycle.

[0031] Example 1: Please see Figure 1 The embodiments of this application provide a method for implementing cross-programming language function calls, applicable to a local interactive terminal, including S1~S3, and the specific implementation steps are as follows: S1. Send a function call request to the web page; wherein, the call parameters corresponding to the function call request are consistent with the interface definition of the function in the programming language used by the web page.

[0032] Step S1 in this embodiment includes S1.1 to S1.5; wherein, S1.1 is the process of establishing a C# DLL function library, S1.2 is the process of establishing a communication connection between the C# client and the web client through middleware, S1.3 to S1.4 is the process of the C# client sending a function call request to the web client, and S1.5 is the process of the web client returning the execution result, specifically as follows: S1.1 Based on the connection module, interaction module, and conversion module, establish a C# dll function library, i.e., the default function library, which will be uniformly referred to as "C# dll function library" in subsequent descriptions; The connection module establishes a connection between the local interactive client and the web client via middleware. Its underlying connection logic is as follows: First, when the web client initiates a local program call request, the middleware receives the request and automatically confirms an available port (e.g., port 888). Then, while starting the local C# program, the middleware synchronously transmits this available port number to the local interactive client. Upon receiving the port number, the local interactive client immediately starts a dedicated WebSocket listening service based on that port. This service not only accurately receives the return value after the function call from the web client but also ensures low latency and reliability for subsequent bidirectional communication, providing underlying link guarantees for cross-language function calls. The C# program is a locally executable C# language program, and the C# client is the local overall environment containing the C# program and its supporting components. The C# program is the core execution carrier of the C# client, relying on other components of the C# client to achieve cross-language function calls. Furthermore, in this embodiment of the invention, the local interactive client specifically refers to the C# client, and will be consistently referred to as the "C# client" in subsequent descriptions; the web client specifically refers to the browser web client, and will be consistently referred to as the "web client" in subsequent descriptions.

[0033] The interaction module is used to send function call requests to the web client via a preset protocol and to obtain the corresponding execution results. Its underlying interaction logic is as follows: On one hand, the C# DLL library has a built-in dedicated low-level interface for cross-language function calls, covering sub-functions such as request encapsulation, message sending, and result monitoring; on the other hand, when the C# client initiates a function call request, it follows a preset protocol to structurally encapsulate the call information. This protocol must explicitly include the object ID corresponding to the non-static function, the class name corresponding to the static function, the target function name, and the parameter list. The encapsulated request is then sent to the web client via the aforementioned WebSocket link. After the request is sent, the interaction module controls the C# client to start a real-time listening mechanism, continuously monitoring the WebSocket message callbacks until the execution result returned by the web client is received. Simultaneously, it triggers the subsequent connection process with the conversion module, ensuring a closed loop in the call chain.

[0034] The conversion module is used to convert object IDs in the execution result to their corresponding objects on the local interactive end, convert result strings to arrays, and convert result strings to numbers. Its underlying conversion logic is as follows: When calling TypeScript functions from the C# side, the return values ​​often involve non-string types such as objects, arrays, and numbers. In this case, the conversion module achieves adaptation through three core underlying methods: ① If the return value is an object ID, the module will match and create the corresponding local object instance based on the "id-object mapping relationship" maintained on the C# side, ensuring that the C# side can directly operate on objects that are from the same source as the web side; ② If the return value is a string and needs to be converted to an array, the module will use standardized methods such as JSON parsing to parse the string into an array type that can be recognized by the C# side according to a preset format, and at the same time perform data integrity verification to avoid parsing errors; ③ If the return value is a string that needs to be converted to a number, the module will first perform a number format validation on the string, and then perform a type conversion to ensure that the precision of the converted data is consistent with the result returned by the web client.

[0035] For examples of this application, please refer to [link / reference]. Figure 2 , Figure 2 The connection establishment and communication process diagram provided in this application embodiment illustrates the process of building a communication link between the browser web client, middleware, and C# client; The browser web client can be various online application platforms, such as 3D design platforms, where users log in and use the platform's functions through the browser; the middleware needs to be installed on the local device, and during installation, it provides an option to start automatically on boot and a corresponding mechanism. After booting, it will automatically shrink to the system taskbar, without affecting user operation at all.

[0036] When a user triggers a local program call operation on the web client, the web client will send a request to the middleware's specified port (such as port 999), and the request will contain the name of the local program to be launched; After receiving a request, the middleware first confirms an available port, then starts the corresponding local program, and synchronously transmits the available port to the C# client and the Web client. After completing these operations, the middleware's processing task for this local program startup request ends, and it continues to listen for new local program startup requests. Its core function is to receive Web client call instructions, allocate communication ports, and start local programs, thus establishing a basic communication link between the C# client and the Web client.

[0037] The C# DLL library provides the ability to initialize the calling environment and various functional interfaces. It is a collection of functions that can be directly called by the local program caller, providing underlying support for cross-language function calls.

[0038] This embodiment, S1.1, provides structured support for cross-programming language function calls by clearly defining the division of labor among the three major modules of the C# DLL function library: connection, interaction, and conversion. The connection module establishes the communication foundation between the local interactive end and the web end using middleware, ensuring stable and reliable cross-end connections. The interaction module standardizes the request sending and result acquisition process through a preset protocol, reducing call failures caused by inconsistent communication formats. The conversion module specifically addresses the mapping between object identifiers and local objects, as well as data type conversion issues, avoiding object reference invalidation or data parsing errors due to language differences. The three modules work together to ensure the orderly operation of each stage of cross-language calls, improve the accuracy and efficiency of calls, and lower the technical threshold for cross-end interaction.

[0039] S1.2 A connection module based on a C# DLL library establishes a communication connection between the C# client and the web client through middleware. Specifically: the web client sends a local program call request to a specified port in the middleware; after receiving the local program call request, the middleware allocates an available port and synchronizes it to both the C# client and the web client; the C# client receives the available port, starts a listening service based on the available port, and establishes a communication connection with the web client after initiating a connection request. Detailed connection logic can be found in the description of the connection module above, and will not be repeated here.

[0040] This embodiment, S1.2, refines the connection establishment process between the local interactive client and the web client. By dynamically allocating available ports through middleware, it effectively avoids conflicts that may be caused by fixed ports, enhancing the flexibility and stability of cross-platform communication. After the web client initiates a request, the middleware synchronizes port information to both ends, ensuring that the local interactive client accurately starts the listening service, making the connection establishment process traceable and controllable. This dynamic port allocation mechanism is particularly suitable for concurrent call requirements in multiple scenarios. It can adapt to complex network environments and simplify the tedious port configuration operations during development, significantly improving the reliability and adaptability of cross-platform connections.

[0041] S1.3 Obtaining the Function Call Request; The "function call request" is an instruction carrier generated by the local caller based on its own business needs. This request must include a target identifier, a function name, and a list of function parameters. Furthermore, the value of the target identifier must match the function type: when calling a non-static function, the target identifier is the object ID; when calling a static function, the target identifier is the class name. The "local caller" specifically refers to the entity running on the C# platform that has cross-language function call requirements. This can be manifested as a desktop application, functional module, or business component developed in C#, and is the core carrier that directly initiates the call and uses the call results within the local C# environment.

[0042] If the function call request is a property operation, the request preprocessing is completed based on the C# dll function library: the target object identifier (i.e., target object id), the target property name (such as the "Name" property to be read or written), and the operation type identifier ("get" represents reading the property, "set" represents setting the property) are added to the function call request, and finally a complete and processed function call request is generated to ensure that the request can accurately locate the property body and behavior to be operated on by the front end; Specifically, the call parameters for the function call request are consistent with the interface definition of the function in the programming language used on the web side. Specifically, the function name, parameter types, and return type of the function call request are identical to the function name, parameter types, and return type of the TypeScript function on the web side. This design eliminates the perceptual barrier of cross-language calls, meaning that C# programmers writing native code do not need to learn the calling rules of TypeScript or manually convert parameter formats, and can obtain a development experience "as if directly calling a function on the web side." It's important to clarify that this "consistency" is limited to formal matching at the interface level. The web interface is the actual carrier of the real data and functional logic for all types and objects. Even if classes, properties, and functions with the same names exist in the local C# environment, they are not complete implementations of the functionality; they are more like an "interface shell." They only retain the names and structures corresponding to the web interface, without containing business logic or data storage themselves. They serve merely as intermediaries for transmitting call instructions and receiving return results, ensuring that instructions are accurately mapped to the actual functionality on the web interface during cross-language calls.

[0043] This embodiment, S1.3, requires that the function name, parameter types, and return value type of the function call request be consistent with the function interface definition on the web page, fundamentally solving the core problem of interface mismatch in cross-language calls. A unified interface definition ensures that requests from the local interactive end can be accurately identified and parsed by the web page, avoiding call failures caused by confused function names, incompatible parameter types, or incorrect return value formats, significantly reducing debugging costs. At the same time, standardized interface specifications facilitate developers' understanding of cross-platform function call logic, reducing the learning cost of cross-language development and improving overall development efficiency and system compatibility. Furthermore, the requirement that function call requests must include a target identifier, function name, and parameter list provides standardized elements for parsing cross-language requests. The target identifier accurately identifies the calling object or class, the function name clearly defines the operation target, and the parameter list ensures the completeness of the call parameters. The combination of these three elements allows the web page to quickly understand the call intent, avoiding parsing errors caused by missing information. This structured request design unifies the information transmission standards for cross-language calls, improves the efficiency and accuracy of request parsing, reduces call failures caused by formatting issues, and ensures the smooth execution of cross-programming language function calls.

[0044] S1.4 After request preprocessing is complete, the C# client sends the processed function call request to the web client via WebSocket, using the interaction module based on the C# DLL library and the available port previously allocated to the C# client by the middleware. This provides a clear instruction basis for the front-end to subsequently find the target object and perform property read / write operations through the ID object manager. Furthermore, when the C# client initiates a function call and the parameters include an object, it does not directly transmit the complete data of the object. Only the web client object identifier corresponding to the object (i.e., the ID associated with the local shell object) is extracted and added to the call request. This cross-language parameter transmission is completed in the form of an identifier, rather than transmitting the object itself. Detailed interaction logic can be found in the description of the interaction module above, and will not be repeated here.

[0045] It's important to note that, aside from property manipulation, the creation of C# native objects also follows a collaborative mechanism of "no direct instance construction on the local side, relying on the core front-end logic." When an object needs to be created, the C# side first initiates a request through the C# DLL library. The core of this request is calling the constructor of the corresponding TypeScript class on the web side. After receiving the request, the web side first executes the class constructor to generate the actual instance, and then the ID object manager assigns a unique identifier (id) to the instance and sends this ID back to the C# side via WebSocket. The C# side does not need to construct the complete data content of the instance; it only creates a "native object shell" associated with the front-end instance based on the ID returned by the front-end. This achieves synchronization between local code operations and the front-end instance state, giving C# developers a seamless experience of "directly manipulating native objects."

[0046] In this embodiment, S1.3-S1.4, for function call requests involving attribute operations, clearly defines the processing logic for adding the target object identifier, attribute name, and operation type identifier, ensuring that the request information is complete and unambiguous. By sending the processed request through a preset protocol and target port, the web interface can quickly identify the operation object, attribute, and specific operation type, avoiding attribute operation errors caused by missing information. This standardized request format design unifies the standard for cross-language attribute interaction, reduces misunderstandings caused by language differences, and improves the accuracy and response efficiency of attribute operation function calls.

[0047] S1.5. As the storage provider for the actual object data, the Web client, upon receiving a function call request from the C# client, will first process the object identifier or creation instruction in the request: if the request contains the identifier of an existing object, it will use the ID object manager to find the corresponding actual object to execute the function logic; if the request is an instruction to create a new object, it will first create an object instance, then assign it an object ID (unique identifier) ​​and return it to the C# client along with the execution result.

[0048] S2. Obtain the execution result from the web page; where the execution result is generated by the web page after locating the target object or target class and executing the corresponding function based on the function call request sent, through a preset object matching mechanism or class matching mechanism.

[0049] Step S2 in this embodiment of the application is specifically as follows: Control the C# side to obtain the execution result from the web side; the execution result is generated by the web side after sending a function call request, which uses a preset object matching mechanism or class matching mechanism to locate the target object or target class and execute the corresponding function.

[0050] The following provides a detailed explanation of the object matching mechanism and the class matching mechanism: ① The object matching mechanism is based on the mapping relationship in the ID object manager. The specific method for obtaining the ID object manager is as follows: All classes in the web application that need to be associated with the C# application inherit from the same predefined base class. The constructor of this predefined base class has built-in logic to call the ID object manager. That is, when an object of the class is instantiated, the manager's method will be automatically triggered to generate an ID, which is a unique object identifier. Using `id` as the key and the object created on the web side as the value, insert it into the global mapping table of the initial `id` object manager to obtain the web-side `id` object manager, which has object matching capabilities. The "global mapping table of the initial `id` object manager" is a global map on the web side used for object matching, and in its initial state, it does not contain key-value pairs of "unique object identifier - web-side object".

[0051] The design of this ID object manager ensures the validity of the association between objects and their identifiers from the source. Whenever the web client generates an object that needs to interact with the C# client, the mapping between its unique identifier and the object itself is synchronously recorded in the ID object manager during instantiation, preventing the matching gap problem of "objects existing but without corresponding identifiers." Regarding the generation method of the unique object identifier, flexible options such as BigInt type auto-increment, UUID generation, or microsecond timestamp generation can be chosen. This embodiment of the invention temporarily adopts the BigInt type auto-increment method, ensuring identifier uniqueness while also considering generation efficiency, avoiding the impact of identifier generation time on cross-language call response speed.

[0052] The object matching mechanism proposed in embodiment S2 is based on an ID object manager. It uses a preset base class to uniformly manage the classes that need to be associated on the webpage, ensuring that each object generates a unique identifier and solving the problem of ambiguous object location in cross-language calls. The mapping relationship, with the unique object identifier as the key and the object as the value, allows the webpage to quickly locate the target object based on the function call request, avoiding matching errors caused by duplicate object names or confused identifiers. The inheritance requirement of the preset base class unifies the object management standard, simplifies the maintenance process of the mapping table, significantly improves the efficiency and accuracy of object matching, and provides fundamental support for the rapid execution of cross-language function calls.

[0053] ② The class matching mechanism is implemented based on the mapping relationship in the class manager. The specific method for obtaining the class manager is as follows: For all classes in the web application that need to be associated with the C# application and have static method call or instantiation (new) requirements, a preset decorator is added to the class name, which is TypeScript syntactic sugar; This decorator is not merely for marking purposes; it contains built-in logic to trigger class manager methods. When the code is loaded into the browser and interpreted, the decorator automatically calls the class manager's registration method, inserting the class name as the key and the corresponding class as the value into the initial class manager's global mapping table. This results in a class manager with class matching capabilities. The "initial class manager's global mapping table" is a global map used for class matching on the web client, which initially does not contain "class name-corresponding class" key-value pairs.

[0054] This class manager design ensures that critical class associations are registered automatically upon loading. No manual registration is required; as soon as the browser's code is parsed, the class name and its mapping are synchronously recorded in the class manager. Subsequently, when the C# client initiates a static method call or requests instance creation, the web client can quickly find the target class in the class manager by its name, avoiding call failures due to unregistered classes and providing stable location support for class-level operations across language scenarios.

[0055] The class matching mechanism in embodiment S2 uses a class manager to automatically register classes that require static method calls or are newly created, employing preset decorators to simplify the preparation work for cross-language calls at the class level. The manager method triggered by the decorator establishes a mapping relationship using the class name as the key, allowing the web page to quickly locate the target class directly by its name, satisfying the needs of static method calls and dynamic creation. This design avoids the tedious operation of manually registering classes, reduces human error, and ensures the efficiency of class matching, improving the response speed and development convenience of cross-language class-level calls.

[0056] S3. Based on the preset function library, convert the object identifier in the execution result into a local object, and convert the target format data into a local data type, obtain the conversion result, and feed the conversion result back to the local caller.

[0057] Step S3 in this embodiment of the application is specifically as follows: The conversion module, based on the C# DLL library, controls the C# side to convert object identifiers in the execution result to local objects and target format data to local data types, obtain the conversion results, and then feed the conversion results back to the local caller.

[0058] For details on how to convert target format data to local data type, please refer to the description of the conversion module above; it will not be repeated here.

[0059] Based on the C# DLL library, the object identifier in the execution result is converted to a native object, specifically as follows: When a function call is initiated from the C# side and the parameters include an object, the complete data of the object is not directly passed. Instead, the web object identifier (i.e., the ID associated with the local shell object) corresponding to the object is extracted and added to the call request. Cross-language parameter passing is completed in the form of an identifier, rather than transmitting the object itself.

[0060] As the storage provider for the actual object data, the web client, upon receiving a call request from the C# client, will look up the corresponding actual object through the ID object manager if the request contains an object identifier; otherwise, if the request is an instruction to create a new object, it will first create an object instance, assign a unique identifier to it, and return it to the C# client.

[0061] If the object identifier in the execution result is the identifier of a newly created object on the web side, it means that the web side has completed the actual construction of the object. At this time, the C# side does not need to replicate the complete data of the object. It only needs to create a local shell object based on the object identifier that is consistent with the object structure definition on the web side, and obtain the transformed local object. The "local shell object" only retains the interface-level information such as class name and property name corresponding to the web side, and does not store real business data. If the object identifier in the execution result is an identifier of an object that already exists on the web side, the C# side directly calls the association mapping stored in the C# DLL library to quickly locate the corresponding local shell object and directly obtain the converted local object. This avoids resource redundancy caused by repeatedly creating shells and ensures that the calling instruction can accurately associate with the target object on the web side. The C# DLL library includes the association mapping between web-side object identifiers and local shell objects. The establishment of this association mapping relies on two types of historical interaction processes: first, when receiving object identifiers returned from the web side, a corresponding local shell is created synchronously and the association between the two is retained; second, after actively creating local shell objects in the past, their mapping relationship with web-side identifiers is recorded in a timely manner.

[0062] It should be noted that the above-mentioned calling mechanism is the "TS function mechanism". Its essence is a data processing system built by the TS side to adapt to cross-language calls: it solves the core problem of "object / class location" through dual managers (id object manager and class manager), and then relies on standardized request processing flow and return value adaptation logic to ensure that the C# side can call TS functions as seamlessly as calling local functions, and finally achieve the core goal of function-level cross-language calls.

[0063] Meanwhile, this TypeScript function mechanism possesses significant standardization characteristics, which can be used to build an automatic C# code generation tool. This tool, combined with the aforementioned calling mechanism, extracts core information from existing TypeScript code, including class definitions, property lists, and the names, parameter types, and return types of basic functions, thereby automatically generating corresponding native C# code. Even if only TypeScript code exists, the generated C# code can be directly called by C# developers without additional manual adaptation. The core function of this automatic code generation tool is to improve C# code generation efficiency through standardization. Furthermore, both the C# and TypeScript sides adhere to a unified virtual function definition specification, relying on middleware communication, object / class management, and the underlying capabilities of DLL libraries to achieve cross-language polymorphic virtual function calls—the C# side only acts as a call "shell" to forward requests, while the actual virtual function logic is executed by the Web-side TypeScript, and the loop is finally completed through return value conversion.

[0064] For examples of this application, please refer to [link / reference]. Figure 3 , Figure 3 The function call mechanism diagram provided in this application embodiment illustrates the cross-language function call logic between the C# client and the Web client based on a unified class definition and API design. The C# client sends a call instruction containing the object ID, class name, and parameters; the Web client then locates the target resource and processes the request through the ID object manager and class manager, subsequently completing data conversion and return value processing, thus fully presenting the entire call flow.

[0065] This embodiment S3 effectively solves the consistency problem of object references in cross-language environments by distinguishing between the identification conversion logic of newly created objects and existing objects. For new objects, a local shell object with a consistent structure is created to ensure that the local interactive end can accurately map the attributes and behaviors of the web-side object; for existing objects, historical shell objects are retrieved through association mapping to avoid resource waste caused by repeated creation, while ensuring the synchronization of object states. The association mapping mechanism in the C# DLL function library establishes a correspondence between object identifiers and local shells based on historical interactions, ensuring the continuity and accuracy of cross-platform object interactions and improving the reliability of cross-language calls for complex objects.

[0066] Overall, the embodiments of the present invention have the following beneficial effects: This invention ensures that function call parameters are consistent with the web interface definition, eliminating adaptation barriers caused by differences in parameter formats and naming rules between different programming languages. It also reduces the workload for developers to write additional conversion logic to adapt to multi-language parameters, thus lowering development complexity caused by parameter incompatibility from the outset. Utilizing a pre-defined object or class matching mechanism, the web interface can accurately locate and execute the target function across differences in object models and class inheritance hierarchies between different programming languages, avoiding function call failures or erroneous executions due to language differences and reducing the repeated debugging costs caused by call location issues during testing. Furthermore, by using a C# DLL library to convert object identifiers to local objects and target format data to local data types, it solves cross-language data compatibility issues. This series of designs, from call request and function execution to result feedback, establishes a seamless cross-language interaction link between the local program and the web program, avoiding extensive adaptation development and frequent compatibility debugging during testing. This effectively solves the problems of difficult implementation, high development and testing costs associated with traditional cross-language function calls. In summary, addressing the practical needs of cross-language function calls between C# and TypeScript, this invention only requires providing the caller with middleware and a C# DLL library. The caller can then directly call the Web-based TypeScript functions to achieve the corresponding functionality without modifying the existing underlying functionality; only the DLL library interface needs to be adapted. This not only allows for cross-language function integration to be completed within a week, significantly reducing time and manpower costs, but also enables C# developers to call Web-based TypeScript functions and generate effects on the Web side as if they were calling local functions when writing programs locally, ultimately achieving seamless cross-language calls.

[0067] Example 2: Please see Figure 4The embodiments of this application provide an implementation device for cross-programming language function calls, which is suitable for local interactive terminals and includes a request module 10, an execution module 20 and a feedback module 30. The request module 10 is used to send function call requests to the web page; the call parameters corresponding to the function call request are consistent with the interface definition of the function in the programming language used by the web page. The execution module 20 is used to obtain the execution result from the web page. The execution result is generated by the web page after sending a function call request, locating the target object or target class and executing the corresponding function through a preset object matching mechanism or class matching mechanism. Feedback module 30 is used to convert the object identifier in the execution result into a local object and the target format data into a local data type according to the preset function library, obtain the conversion result, and feed the conversion result back to the local caller.

[0068] It should be noted that the technical concept of this second embodiment is completely consistent with that of the first embodiment. The two maintain a high degree of synergy at the technical logic level. The specific technical details can be referred to the relevant description of the first embodiment, which will not be repeated here.

[0069] Example 3: This application provides a computer-readable storage medium including a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the method for implementing a cross-programming language function call. The method for implementing cross-programming language function calls, if implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0070] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0071] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for implementing cross-programming language function calls, characterized in that, The local interaction terminal is suitable for local interaction, comprising: sending a function call request to a web terminal; wherein the function call request corresponds to the same calling parameters and interface definition of the programming language function used by the web terminal; obtaining the execution result of the web terminal; wherein the execution result is generated by the web terminal based on the function call request, and the target object or target class is located and the corresponding function is executed by the web terminal through a predetermined object matching mechanism or class matching mechanism; According to the preset function library, the object identifier in the execution result is converted into a local object, and the target format data is converted into a local data type to obtain a conversion result, and the conversion result is fed back to the local calling party.

2. The method of claim 1, wherein the method further comprises: The preset function library comprises a connection module, an interaction module and a conversion module; The connection module is used to connect the local interaction terminal and the web terminal through middleware; The interaction module is used to send a function call request to the web terminal through a predetermined protocol, and obtain the corresponding execution result; The conversion module is used to convert the object id in the execution result into the corresponding object of the local interaction terminal, convert the result string into an array, and convert the result string into a number.

3. The method of claim 2, wherein the method further comprises: The local interaction terminal and the web terminal are connected based on the connection module of the preset function library, specifically: The web terminal sends a local program call request to a specified port of the middleware; After receiving the local program call request, the middleware allocates an available port and synchronizes it to the local interaction terminal and the web terminal; The local interaction terminal receives the available port, starts a listening service based on the available port, and establishes a communication connection with the web terminal after the web terminal initiates a connection request.

4. The method of claim 1, wherein the method further comprises: Sending a function call request to a web terminal, specifically: If the function call request is an attribute operation, the target object identifier, target attribute name and operation type identifier are added in the function call request based on the preset function library to obtain a processed function call request; The processed function call request is sent to the web terminal based on the target port through a predetermined protocol.

5. The method for implementing cross-programming language function calls as described in claim 1, characterized in that, The function call request corresponds to the same calling parameters and interface definition of the programming language function used by the web terminal, specifically: The function name, parameter type and return value type of the function call request are consistent with the function name, parameter type and return value type of the programming language function used by the web terminal.

6. The method for implementing cross-programming language function calls as described in claim 1, characterized in that, According to the preset function library, the object identifier in the execution result is converted into a local object, specifically: If the object identifier in the execution result is the identifier of a newly created object of the web terminal, a local shell object is created in the local interaction terminal based on the object identifier, which is consistent with the object structure definition of the web terminal, to obtain the converted local object; If the object identifier in the execution result is the identifier of the existing object in the webpage end, the corresponding shell object stored in the preset function library is called to obtain the converted local object; the preset function library includes the association mapping of the webpage object identifier and the local shell object, and the association mapping is established based on the interactive process of the historical received object identifier and the historical created shell object.

7. The method for implementing cross-programming language function calls as described in claim 1, characterized in that, The object matching mechanism is realized based on the mapping relationship in the id object manager, and the id object manager is obtained in the following manner: All classes in the webpage end that need to be associated with the local interactive end inherit the same preset base class, and a unique object identifier is generated based on the preset base class; The unique object identifier is used as the key, and the object created by the webpage end is used as the value, and the global mapping table of the initial id object manager is inserted to obtain the id object manager with object matching capability.

8. The method for implementing cross-programming language function calls as described in claim 1, characterized in that, The class matching mechanism is realized based on the mapping relationship in the class manager, and the class manager is obtained in the following manner: For all classes in the webpage end that need to be associated with the local interactive end and have static method calling requirements or instantiation requirements, a preset decorator is added at the class name; The corresponding manager method is called through the decorator, the class name is used as the key, and the class corresponding to the class name is used as the value, and the global mapping table of the initial class manager is inserted to obtain the class manager with class matching capability.

9. The method of claim 1 to 8, wherein, The function calling request includes a target identifier, a function name, and a function parameter list.

10. An apparatus for implementing a cross-programming language function call, the apparatus comprising: It is suitable for the local interactive end, including a request module, an execution module, and a feedback module; The request module is configured to send a function calling request to the webpage end; the calling parameters of the function calling request and the interface definition of the programming language function used by the webpage end are consistent; The execution module is configured to obtain an execution result of the webpage end; the execution result is generated based on the sent function calling request, and the webpage end locates a target object or a target class and executes a corresponding function through a preset object matching mechanism or a class matching mechanism; The feedback module is configured to convert an object identifier in the execution result into a local object based on a preset function library, and convert target format data into a local data type to obtain a conversion result, and feed back the conversion result to a local calling party.

11. A storage medium, characterized by The storage medium stores a computer program, and the computer program is called and executed by a computer to realize the implementation method of the cross-programming language function calling according to any one of claims 1 to 9.

12. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instruction is executed by the communication device to realize the implementation method of the cross-programming language function calling according to any one of claims 1 to 9.

Images