I had some ideas on how this could be implemented and I wanted to join the crowd.
I thought this out very carefully after reviewing the things previously suggested in this thread and included as many of the good things as I could and even added one or two. Even though Fred has already fashioned many (if not all) of his ideas about this I still wanted to make my suggestions.
The only special 'operator' required would be '\\' and it would allow access to elements that are within a module. My idea is to allow everything to be included within the limited scope of a module. That means not only variables, but also constants, procedures, structures, prototypes, interfaces and labels. The only thing excluded would be macros (but they are covered by UndefineMacro).
Anyway, here's my outline of how things would work:
Code: Select all
Module module_name
#colorCount = 5
Structure test
a.l
b.w
EndStructure
Global x.f
Define y.f
Prototype.w boxC(window, maxColors = 0)
Interface myObject
move(x,y)
moveF(x.f, y.f)
destroy()
EndInterface
DataSection
initDataStart:
Data.i 3, 5, 7, 9
initDataEnd:
EndDataSection
;if a macro should not be available outside scope it should be undefined before ending module scope
Macro trip(a)
Debug a
EndMacro
;Only those things which are between Export/EndExport are accessible outside the module's scope
;things coming before or afterwards are not.
Export
#patternCount ;constant declaration or enumeration
Global a.i ;Global declaration
Define b.i ;Define declaration
Structure vector: x.b: y.b: c.b: EndStructure ;Structure delcaration
Prototype.w shape(operation, maxColors = 0) ;Prototype declaration
;Interface declaration, no example provided
;Labels in DataSections are exported by including the datasection here (Export/EndExport)
DataSection
versionInfo:
Data.s "Beta v300 build 12"
EndDataSection
;procedures via a Declare declaration
Declare boxCallback(a.s, m = #colorCount)
EndExport
Procedure boxCallback(a.s, m = #colorCount)
EndProcedure
EndModule
;-------- Summary of additional language operations ------------------
;
;Module module_name/EndModule ;Define Module scope
;Export/EndExport ;Define elements that are usable by name outside Module scope
;
;Exported elements from module scope are referenced by placing the module_name before them and adding '\\'
; so that procedure box() in module 'primitives' would be referenced as 'primitives\\box()'. If the element
; is a constant then the '#' comes in front of the module name (i.e. #primitives\\patterncount).
; Structures and Prototypes are referenced by placing the qualified name after the '.' (i.e. x.primitives\\vector).
;
;IncludeModule module_name/ExcludeModule module_name ;allow/disallow unqualified access to exported elements
;ImportModule module_name As newname ;Change a module's qualifier (i.e. name)
;IncludeFromModule module_name/EndIncludeFromModule ;allow unqualified access only to specified exported elements
;
;
;Modules cannot be nested in their declaration, that is only one Module can be defined between each Module/EndModule.
;They can be nested in their qualfied paths by using a subpath as part of the modules name when declaring them.
Module first
#height = 3
EndModule
Module first\\second
Export
Define action = 12
EndExport
EndModule
;If a module has sub-modules defined then their elements may be refenced by including the complete qualfied name,
;i.e. 'first\\second\\action'. When UseModule is included then only the portion of the sub-module's name
;which wasn't specified would need to be used (i.e. 'UseModule first: second\\action = 10').
I know Fred has said he would like to use '_' as the operator for appending a module name. I think this would create conflicts and would hide, at least in part, what would be taking place when referencing things withing a module. Using '\\' as the operator is similar to the use of '\' to reference a structure's fields and I think it would be a reminder that we are really specifying a 'path' to a variable or element (much like a file). It would also be something that wouldn't conflict with names that don't have anything to do with a particular module and so avoids accidental name collisions. The only downside I see is first that it is two characters instead of one. Second is the idea that it may be the result of a mistyped reference to a structure's field. I don't foresee either of these being serious enough to persuade against its use.
I had thought about trying to setup a preprocessor in the IDE that would handle things using the syntax that I have described but I haven't yet had the time to attend to it.
