Get rid of options: [private] for private modules, and add options: [lib] for non-private modules. The main reason for this is to encourage more-modular development by default.
For regular modularity, private modules are much better. They are more useful for utility modules, allow developers to be more careful about what they import, and where they import it. For developers of modular code, these are the modules that they would normally want to use. Their private import even allows them to have multiple running versions of the same support modules, as long as those changes are isolated from each other.
The main purpose of non-private modules is to create high-level components for adding stuff to the runtime library, lib. Non-private modules are basically Rebol's version of the components of "component-based programming". Such modules need to be careful about what they export, because their exports are imported into everywhere else by default. They need to be managed at the top level of the app, where potential name collisions can be resolved. For that matter, these components can be upgradable at runtime, which the strong-modularity constraints of private modules won't allow. They're really important for whole-application management, but they're a bit more advanced.
It sends the right message to have the modules that we recommend for modular programming be the "regular" modules, while having the global modules be considered something special, since they serve a more advanced and specific purpose.
Regular scripts would keep the same semantic model. Both module types work basically the same when imported by scripts.
Changed proposed option from global to lib, because "global" is not a very precise term for what effect this will have on modules. It doesn't cause modules to export "globally", per-se, it causes them to export to lib. Then everything else imports from lib, eventually. So not immediately global, just global going forward.
It's basically the exact opposite of IMPORT's /no-lib option, which should make things easier to understand (according to Oldes/Rebol-issues#1807). We wouldn't need to change the /no-lib or /no-user options, they would make even more sense with this option. It also has the advantage of mentally linking to the "lib" concept, and being smaller as well.
Rebolbot commented on Mar 2, 2015:
Submitted by:BrianH
As part of this change in defaults, the MIXIN? function is even less necessary or appropriate. It basically returned true for (formerly) private modules with exports, but this distinction may not be appropriate with the new model. We'll see if the function will still be useful internally.
Submitted by: BrianH
Get rid of options: [private] for private modules, and add options: [lib] for non-private modules. The main reason for this is to encourage more-modular development by default.
For regular modularity, private modules are much better. They are more useful for utility modules, allow developers to be more careful about what they import, and where they import it. For developers of modular code, these are the modules that they would normally want to use. Their private import even allows them to have multiple running versions of the same support modules, as long as those changes are isolated from each other.
The main purpose of non-private modules is to create high-level components for adding stuff to the runtime library, lib. Non-private modules are basically Rebol's version of the components of "component-based programming". Such modules need to be careful about what they export, because their exports are imported into everywhere else by default. They need to be managed at the top level of the app, where potential name collisions can be resolved. For that matter, these components can be upgradable at runtime, which the strong-modularity constraints of private modules won't allow. They're really important for whole-application management, but they're a bit more advanced.
It sends the right message to have the modules that we recommend for modular programming be the "regular" modules, while having the global modules be considered something special, since they serve a more advanced and specific purpose.
Regular scripts would keep the same semantic model. Both module types work basically the same when imported by scripts.
Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ] Imported from: https://github.com/rebol/rebol-issues/issues/2115
Comments:
Submitted by: BrianH
Changed proposed option from global to lib, because "global" is not a very precise term for what effect this will have on modules. It doesn't cause modules to export "globally", per-se, it causes them to export to lib. Then everything else imports from lib, eventually. So not immediately global, just global going forward.
It's basically the exact opposite of IMPORT's /no-lib option, which should make things easier to understand (according to Oldes/Rebol-issues#1807). We wouldn't need to change the /no-lib or /no-user options, they would make even more sense with this option. It also has the advantage of mentally linking to the "lib" concept, and being smaller as well.
Submitted by: BrianH
As part of this change in defaults, the MIXIN? function is even less necessary or appropriate. It basically returned true for (formerly) private modules with exports, but this distinction may not be appropriate with the new model. We'll see if the function will still be useful internally.