| Type | Issue | Status | tested | Date | 4-Aug-2009 22:57 |
|---|---|---|---|---|---|
| Version | alpha 76 | Category | Mezzanine | Submitted by | BrianH |
| Platform | All | Severity | major | Priority | high |
| Summary | Import of an unnamed module doesn't reload properly |
|---|---|
| Description |
The documentation and articles about modules state that the module should have a Name field in its header so it won't be reloaded, and can thus be shared by all of the modules and scripts loaded in REBOL. This is why the exported words of named modules are all exported to a common exports context - that way you can explicitly manage overrides and precedence of the exported words, protect the words, etc. The same documentation and articles either imply or state explicitly that modules that *don't* have a Name field, *should* be able to be reloaded, and that reloading them is the expected behavior. Unfortunately, this behavior is currently broken, and doesn't have a good model for how it is supposed to work. I propose that unnamed modules be treated as mixins. Their exports would not be added to the common exports context - this is why reloading is currently broken. Instead, their exports would be imported into the context that is currently requesting the module, generally in their Needs header. The precedence of these mixins would be lower than the words in the shared exports of the named modules, which are in turn lower in the words in the system context. This would probably require that the mixins be applied in the DO-NEEDS function. The advantage of mixins is that they would be recreated every time, and then integrated locally. This lets you reuse code that needs to be copied rather than shared - code that provides local services to a module, for instance. This can be taken advantage of when you are trying to combine code from different sources, for backwards-compatibility and versioning, and for a wide variety of other uses. With a clean model for mixins we can handle the complex situations that can't be handled by the simple-to-manage model we adopted for named modules. It should help balance the system. (Submitted as an Issue since this is both a Bug report and a Wish.) |
| Example code |
| Assigned to | n/a | Fixed in | alpha 81 | Last Update | 3-Sep-2009 07:29 |
|---|
| Comments | |
|---|---|
|
(0001582)
BrianH 3-Sep-2009 07:29 |
Note: Because #1186 was dismissed, the mixin export process can't be done in DO-NEEDS, except for user scripts (where the context is known). Because of this, DO-NEEDS now returns an object containing the mixin words, or #[none] if there are none. IMPORT and DO add that object to the module's spec object in the 'mixins field, before MAKE module! is called. This allows MAKE module! to apply the mixins. The 'mixins spec field is set to #[true] afterwards, to indicate that there were mixins (FYI), but not show them in case they're private. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 3-Sep-2009 07:29 | BrianH | Comment : 0001582 | Added | - |
| 3-Sep-2009 07:20 | BrianH | Fixedin | Modified | => alpha 81 |
| 3-Sep-2009 07:20 | BrianH | Status | Modified | pending => tested |
| 5-Aug-2009 00:19 | BrianH | Description | Modified | - |
| 5-Aug-2009 00:19 | BrianH | Status | Modified | submitted => pending |
| 4-Aug-2009 22:57 | BrianH | Ticket | Added | - |