REBOL3 tracker
  0.9.12 beta 		Ticket #0002116 User: anonymous

Project:
Login | View Tickets



rss
TypeWish Statuspending Date26-Feb-2014 04:50
Versionr3 master CategoryMezzanine Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary Add word to module-local contexts to refer to the local lib
Description 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.
Example code 

					
		

	


	

		

			Assigned ton/a
			Fixed in-
			Last Update3-Mar-2015 10:38
		

	

	
		

	

	







	
Comments

	
	

		
			(0004277)
			
BrianH
28-Feb-2014 03:49


			
				
		
			
				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.
			
		
	

	
	

		
			(0004278)
			
abolka
28-Feb-2014 04:15


			
				
		
			
				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.
			
		
	

	
	

		
			(0004362)
			
acook
9-Mar-2014 04:27


			
				
		
			
				Given that we're getting rid of the "private" options when defining modules (#2115) 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.
			
				
	

	
	

		
			(0004363)
			
BrianH
9-Mar-2014 04:31


			
				
		
			
				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.
			
		
	

	
	

		
			(0004578)
			
BrianH
2-Mar-2015 12:55


			
				
		
			
				One question: Should there always be a 'local-lib word set, and should it always be set to an object? We have three possibilities:

    

  1. 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.
    2. 

  2. 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?.
    3. 

  3. 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.
    4. 



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.
			
				
	

	
	

		
			(0004583)
			
BrianH
3-Mar-2015 10:17


			
				
		
			
				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 #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.
			
				
	

	
	

		
			(0004584)
			
BrianH
3-Mar-2015 10:29


			
				
		
			
				PR: https://github.com/rebol/rebol/pull/236
			
		
	

	
	

		
			(0004585)
			
BrianH
3-Mar-2015 10:38


			
				
		
			
				Adjusted the description of the ticket to reflect the above discussion.
			
		
	

		
	








	

		Date
		User
		Field
		Action
		Change
	

	
	

		3-Mar-2015 10:38
		BrianH
		
			Comment : 0004585
		
		Added
		-
	

	
	

		3-Mar-2015 10:38
		BrianH
		
			Description 
		
		Modified
		-
	

	
	

		3-Mar-2015 10:29
		BrianH
		
			Status 
		
		Modified
		submitted => pending
	

	
	

		3-Mar-2015 10:29
		BrianH
		
			Comment : 0004584
		
		Added
		-
	

	
	

		3-Mar-2015 10:17
		BrianH
		
			Comment : 0004583
		
		Modified
		-
	

	
	

		3-Mar-2015 10:17
		BrianH
		
			Comment : 0004583
		
		Added
		-
	

	
	

		3-Mar-2015 09:50
		BrianH
		
			Comment : 0004578
		
		Modified
		-
	

	
	

		2-Mar-2015 12:55
		BrianH
		
			Comment : 0004578
		
		Added
		-
	

	
	

		9-Mar-2014 04:31
		BrianH
		
			Comment : 0004363
		
		Added
		-
	

	
	

		9-Mar-2014 04:29
		BrianH
		
			Summary 
		
		Modified
		Add word to module-local contexts to refer to the private lib => Add word to module-local contexts to refer to the local lib
	

	
	

		9-Mar-2014 04:27
		acook
		
			Comment : 0004362
		
		Modified
		-
	

	
	

		9-Mar-2014 04:27
		acook
		
			Comment : 0004362
		
		Added
		-
	

	
	

		3-Mar-2014 21:14
		BrianH
		
			Description 
		
		Modified
		-
	

	
	

		3-Mar-2014 21:14
		BrianH
		
			Summary 
		
		Modified
		Add word to module-local contexts to refer to the private library => Add word to module-local contexts to refer to the private lib
	

	
	

		28-Feb-2014 04:15
		abolka
		
			Comment : 0004278
		
		Added
		-
	

	
	

		28-Feb-2014 03:49
		BrianH
		
			Comment : 0004277
		
		Added
		-
	

	
	

		26-Feb-2014 05:01
		BrianH
		
			Description 
		
		Modified
		-
	

	
	

		26-Feb-2014 04:50
		BrianH
		
			Ticket 
		
		Added
		-
	

		






Copyright @ 2007-2010 Softinnov
- Powered by Cheyenne