REBOL3 tracker
  0.9.12 beta
Ticket #0001180 User: anonymous

Project:



rss
TypeWish Statusdismissed Date4-Aug-2009 23:25
Versionalpha 76 CategoryMezzanine Submitted byBrianH
PlatformAll Severityblock Priorityhigh

Summary DO-NEEDS /into context option
Description Right now, the binding or resolving behavior of scripts and modules is scattered amongst the IMPORT mezzanine and the DO, MAKE-MODULE and BEGIN intrinsics. This makes it difficult to keep track of the proper import and binding behavior of system and user scripts, and regular and isolated modules. And without the proper wrapper code, processing of the Needs header just doesn't work. It would be better to move this various code into DO-NEEDS itself.

I propose that DO-NEEDS handle the expansion and initialization of the shared user context for mixins applied to user scripts (see #1178) by default - the rest of the user script binding issues can be handled by LOAD and DO.

For modules, I propose that DO-NEEDS get an /into context [object! block!] option. The /into block! option would bind the shared system, shared exports and mixins to the code block of a regular module, with proper precedence. The /into object! option would resolve the shared system, shared exports and mixins to an isolated module context. DO-NEEDS/into would be called by MAKE-MODULE instead of the binding/resolving code there.

This would allow us to properly manage the shared contexts in %mezz-load.r and remove most of that management code from %mezz-intrinsics.r, and also make DO-NEEDS more useful for standalone use. It could also help if we decide to do access controls on the shared contexts.
Example code

			

Assigned ton/a Fixed in- Last Update21-Aug-2009 07:12


Comments
(0001537)
BrianH
21-Aug-2009 07:12

Since #1186 was dismissed, the workaround requires the mixins to be returned so that they can be passed into MAKE-MODULE. This means that the code that would be called by the /into option has been moved into MAKE-MODULE, and that there really isn't a way to implement the /into option without it being too awkward, and no reason to try.

Instead, an /only option was implemented. The default is to apply any mixins to the user context (see #1178). With /only the mixins are not applied.

If there are any mixins, an object containing them is returned. Otherwise, none is returned.

Date User Field Action Change
21-Aug-2009 07:12 BrianH Comment : 0001537 Added -
21-Aug-2009 07:05 BrianH Status Modified pending => dismissed
5-Aug-2009 00:24 BrianH Severity Modified major => block
5-Aug-2009 00:20 BrianH Description Modified -
5-Aug-2009 00:20 BrianH Status Modified submitted => pending
4-Aug-2009 23:25 BrianH Ticket Added -