Code inclusion rework

belliash kommenterad

2019-11-02 11:39:22 +01:00

Ägare

Actually, we got 2 builtin function: include() and require(). Both of them are available only inside methods body. The proposition is to:

make 'require' available only on the global scope in order to include source files containing classes.
make 'include()' available only inside methods body, to include a part of code that will be executed during method call. Such code should be a valid AerScript code that can be executed inside method body (just like using 'eval()')

Thus 'include()' would be still a builtin function, while 'require' would become a language construct. Having that, 'include()' should allow to include code several times (i.e. in loop), while require should work as 'require_once'.

Actually, we got 2 builtin function: include() and require(). Both of them are available only inside methods body. The proposition is to: * make 'require' available only on the global scope in order to include source files containing classes. * make 'include()' available only inside methods body, to include a part of code that will be executed during method call. Such code should be a valid AerScript code that can be executed inside method body (just like using 'eval()') Thus 'include()' would be still a builtin function, while 'require' would become a language construct. Having that, 'include()' should allow to include code several times (i.e. in loop), while require should work as 'require_once'.

belliash added the

bug

enhancement

labels 2019-11-02 11:39:22 +01:00

belliash added

idea

and removed

bug

labels 2019-11-02 11:49:27 +01:00

belliash kommenterad

2019-11-02 11:53:09 +01:00

Author

Ägare

Additionally, 'import()' allows to load a shared AerScript module. Actually it is implemented as a built-in function returning TRUE on success, or FALSE otherwise. This gives the control to the software developer on potential fallback or throwing an exception it module is not available, when called from constructor for example. If we decide to rewrite it as language construct it would need to throw exception without ability to catch it from global scope.

Decision? I vote for having 'include()' and 'import()' builtin methods and 'require' language construct.

Additionally, 'import()' allows to load a shared AerScript module. Actually it is implemented as a built-in function returning TRUE on success, or FALSE otherwise. This gives the control to the software developer on potential fallback or throwing an exception it module is not available, when called from constructor for example. If we decide to rewrite it as language construct it would need to throw exception without ability to catch it from global scope. Decision? I vote for having 'include()' and 'import()' builtin methods and 'require' language construct.

belliash refererade till detta ärende från en incheckning

2019-11-27 20:13:31 +01:00

Code inclusion rework that include several changes (#58): * include() builtin function allows now to include a chunk of code, eg. a body of some loop * include() allows to load and execute file several times * require() still allows to include file just once and included file must have a valid OOP syntax * both functions will throw E_ERROR when impossible to include specified file

belliash refererade till detta ärende från en incheckning

2019-12-09 19:33:04 +01:00

Rework including mechanism (#58) related changes: * VmExecIncludedFile() does not need a call context * Builtin include() function does not need to return false, it throws an error

belliash refererade till detta ärende från en incheckning

2019-12-10 16:11:54 +01:00

Another changes in file inclusion mechanism (#58): * Remove builtin functions: 'include' & 'require' * Implement 'include' and 'require' statements compiler * Implement OP_INCLUDE operator * Allow 'require' statement to be used in global scope as well as in method body and 'include' only in method body

belliash refererade till detta ärende från en incheckning

2019-12-14 23:30:48 +01:00

Reimplement import() builtin function as a global-scope statement. This fixes #58.