You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 28, 2022. It is now read-only.
module an.other.One
import my.package.Utils
function main = |args| {
foo(1, 2)# actually calls some.Module::foo
bar("plop")# ! no such method...}
It would ease the creation of facade module for instance.
I see two ways to do this:
compile time (e.g. with a macro... which should be available soon) by injecting in the exporting module functions that delegate on the original ones. Advantage: no change to the language if macros are used, no change in the resolution process, easier to implement. A drawback is that the exported module must be available at compile time to do reflection (depending on the features we want, for instance exporting all functions or keeping named parameters), and thus the compilation order becomes relevant;
run time by adding some export metadata to a module (in the same spirit as imports) and use this information when resolving a function call: also search functions in modules exported by the modules imported in the module containing the call... more change to the language/runtime, more difficult to implement, but more dynamic and compilation order remains irrelevant.
Ideas?
The text was updated successfully, but these errors were encountered:
It would be nice for a module to be able to expose (export) some or all public functions defined in an other module.
For instance, given
a module can export some functions as (syntax to be defined)
so that a third one can do:
It would ease the creation of facade module for instance.
I see two ways to do this:
compile time (e.g. with a macro... which should be available soon) by injecting in the exporting module functions that delegate on the original ones. Advantage: no change to the language if macros are used, no change in the resolution process, easier to implement. A drawback is that the exported module must be available at compile time to do reflection (depending on the features we want, for instance exporting all functions or keeping named parameters), and thus the compilation order becomes relevant;
run time by adding some export metadata to a module (in the same spirit as imports) and use this information when resolving a function call: also search functions in modules exported by the modules imported in the module containing the call... more change to the language/runtime, more difficult to implement, but more dynamic and compilation order remains irrelevant.
Ideas?
The text was updated successfully, but these errors were encountered: