| Type | Wish | Status | submitted | Date | 26-Feb-2014 04:19 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Mezzanine | Submitted by | BrianH |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Make private module export the default, exporting through lib an option |
|---|---|
| Description |
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. |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 2-Mar-2015 11:59 |
|---|
| Comments | |
|---|---|
|
(0004270)
BrianH 26-Feb-2014 17:59 |
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 #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. |
|
(0004577)
BrianH 2-Mar-2015 11:59 |
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. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 2-Mar-2015 11:59 | BrianH | Comment : 0004577 | Added | - |
| 26-Feb-2014 19:29 | BrianH | Summary | Modified | Make private module export the default, export through lib an option => Make private module export the default, exporting through lib an option |
| 26-Feb-2014 18:00 | BrianH | Comment : 0004270 | Modified | - |
| 26-Feb-2014 17:59 | BrianH | Comment : 0004270 | Added | - |
| 26-Feb-2014 17:45 | BrianH | Summary | Modified | Make private module export the default, global export an option => Make private module export the default, export through lib an option |
| 26-Feb-2014 17:45 | BrianH | Description | Modified | - |
| 26-Feb-2014 04:21 | BrianH | Description | Modified | - |
| 26-Feb-2014 04:19 | BrianH | Ticket | Added | - |