Just as lib modules export to the lib object, non-lib modules, when requested by another module, export to an object as well. It helps for collecting local imports, managing overrides, same as lib. That object is currently unnamed.
For the same reasons that we would want to refer to lib, we would also want to refer to that object. Maybe you want to manually fix up the overrides, maybe you want to get access to stuff that got overridden by your module-local stuff, or by function options, whatever.
So, let's add a word to the module's context which refers to this object. Let's call it "local-lib".
If we assign the value none to that name if there are no local imports, that would make it easier for modules to detect this if they need to. On the other hand, if we assigned it an empty object by default then it would be just as easy to use EMPTY? to detect that case, and other uses of the word wouldn't need as much conditional code.
Local imports to scripts don't work the same way as they do to modules - there is no separate object, the imports go right into the user object. However, if we assign 'local-lib to refer to that context then we'll have it as a shortcut to refer to it, like 'lib is a shortcut for system/contexts/lib. It will have the added benefit of blocking any lib exports of that word from causing problems.
It's worth noting that the MODULE function's /mixin option takes exactly this object as a parameter. We might want to unify the naming a little.
Rebolbot commented on Feb 28, 2014:
Submitted by:abolka
On the naming: I'd slightly prefer private-lib, even though it's a bit longer. I envision it being seldomly used in practice (and typically by very specialised code), which would well warrant the more explicit name.
I propose "local-lib" which seems to bind more tightly with the problem domain.
Rebolbot commented on Mar 9, 2014:
Submitted by:BrianH
Yeah, that's much better. I have to remember to update the terminology and phrasing of all of the module epic tickets, at least that refer to current stuff.
Rebolbot commented on Mar 2, 2015:
Submitted by:BrianH
One question: Should there always be a 'local-lib word set, and should it always be set to an object? We have three possibilities:
We always have 'local-lib initially set to an object in every module, but that object would be empty if there are no words imported locally (from non-lib modules). That word would always be set after the other words are bound and set, but before the module code starts running. It would override any imported meaning of that word, and you could check whether the object was empty if you're curious about whether there were any exports into it. This would have the advantage of speeding up code that uses the object for anything other than a namespace.
We always have 'local-lib set in every module, but set to none if there were no imports. This has the advantage of not allocating an extra empty object for modules that don't need it, but it makes operations that use 'local-lib have to be guarded by conditional code, with very little benefit over the noop behavior of BIND or check of EMPTY?.
We don't set 'local-lib in the module unless there will be words in it. Basically, the same as option 2 but with even worse conditional code.
I'm leaning towards option 1, since it defining it consistently and making it always an object would be consistent with 'lib and easier to explain.
Rebolbot commented on Mar 3, 2015:
Submitted by:BrianH
Another issue is how we deal with the issue of silly modules trying to export their local-lib words. However, we don't want to blacklist the word from exports because it will be too difficult to do when you consider Oldes/Rebol-issues#2114, and likely a bad idea even then. For modules it won't be an issue since we can set 'local-lib after all of the other exports are done, but for scripts it's a different issue because they don't actually have the referred-to object as a concept.
I think the best solution for scripts is to just preset the word 'local-lib in the script context to refer to the script context itself. Let it be a shortcut way to refer to system/contexts/user, the way 'lib is a shortcut for system/contexts/lib. Then it won't matter in your scripts what the word has in lib, since imports to the script context don't override existing values unless you do so explicitly.
Submitted by: BrianH
Just as lib modules export to the lib object, non-lib modules, when requested by another module, export to an object as well. It helps for collecting local imports, managing overrides, same as lib. That object is currently unnamed.
For the same reasons that we would want to refer to lib, we would also want to refer to that object. Maybe you want to manually fix up the overrides, maybe you want to get access to stuff that got overridden by your module-local stuff, or by function options, whatever.
So, let's add a word to the module's context which refers to this object. Let's call it "local-lib".
If we assign the value none to that name if there are no local imports, that would make it easier for modules to detect this if they need to. On the other hand, if we assigned it an empty object by default then it would be just as easy to use EMPTY? to detect that case, and other uses of the word wouldn't need as much conditional code.
Local imports to scripts don't work the same way as they do to modules - there is no separate object, the imports go right into the user object. However, if we assign 'local-lib to refer to that context then we'll have it as a shortcut to refer to it, like 'lib is a shortcut for system/contexts/lib. It will have the added benefit of blocking any lib exports of that word from causing problems.
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/2116
Comments:
Submitted by: BrianH
It's worth noting that the MODULE function's /mixin option takes exactly this object as a parameter. We might want to unify the naming a little.
Submitted by: abolka
On the naming: I'd slightly prefer private-lib, even though it's a bit longer. I envision it being seldomly used in practice (and typically by very specialised code), which would well warrant the more explicit name.
Submitted by: acook
Given that we're getting rid of the "private" options when defining modules (https://github.com/Oldes/Rebol-issues/issues/2114) I don't think it makes sense any longer to link those two terms.
I propose "local-lib" which seems to bind more tightly with the problem domain.
Submitted by: BrianH
Yeah, that's much better. I have to remember to update the terminology and phrasing of all of the module epic tickets, at least that refer to current stuff.
Submitted by: BrianH
One question: Should there always be a 'local-lib word set, and should it always be set to an object? We have three possibilities:
I'm leaning towards option 1, since it defining it consistently and making it always an object would be consistent with 'lib and easier to explain.
Submitted by: BrianH
Another issue is how we deal with the issue of silly modules trying to export their local-lib words. However, we don't want to blacklist the word from exports because it will be too difficult to do when you consider Oldes/Rebol-issues#2114, and likely a bad idea even then. For modules it won't be an issue since we can set 'local-lib after all of the other exports are done, but for scripts it's a different issue because they don't actually have the referred-to object as a concept.
I think the best solution for scripts is to just preset the word 'local-lib in the script context to refer to the script context itself. Let it be a shortcut way to refer to system/contexts/user, the way 'lib is a shortcut for system/contexts/lib. Then it won't matter in your scripts what the word has in lib, since imports to the script context don't override existing values unless you do so explicitly.
Submitted by: BrianH
PR: https://github.com/rebol/rebol/pull/236
Submitted by: BrianH
Adjusted the description of the ticket to reflect the above discussion.