Modules
Posted: Mon Aug 08, 2005 1:16 pm
When programming projects get to a certain size PureBasic starts to struggle.
The biggest problem is all the global stuff. Especially Arrays and Linked Lists.
It would be great if there was modular support.
At the moment we have a Global Space. Inside that global space exist all of the procedures, arrays, linked lists, global variables and object cursors.
By object cursors I mean the current object being used for images, files, databases, libraries, etc.
It would be great if the global space could be replaced with a module space. All of these global objects would then be contained within a module space.
There would be a default module, which everything would be contained in by default. This would mean that existing code would work without alteration inside the default module.
If a user calls 'UseModule(module_name) then control would switch to that module. UseModule() without a name would return control to the default modele.
For example, the following code would debug 7 followed by 5:
I'm sure the benefits of this would be obvious to anybody who has tried to write a library.
A command should exist for renaming modules, with settings available in the IDE. This will help to work around any name clashes that might occur.
So, for example, if both Joe and Bob have a My_HashTable Module and you want to use both the code can do this:
It should also be possible to Include and exclude modules into the default space.
For example IncludeModule(Joes_HashTable) would merge both the current module and the default space. ExcludeModule(Joes_HashTable) would then remove it. Then you could do this:
An optional 'Prefix' paramater would also be useful so that if Joes_Hashtable included the linked lists AllHashes() then a call to IncludeModule(Joes_HashTable, "Joes_" would make the procedure Joes_AllHashes() available in the default space.
Taking it further, module spaces could be created for older versions of the purelibraries. For example, all the hassles brought with the memory changes to memory could have been avoided. UseModule(Default_3.81) would return behaviour for AllocateMemory and the rest to the pre-3.90 style. Old code could be wrapped just have to be wrapped in these to ensure legacy support.
Even better, their could be module like 'Removed_In_3.90' and 'Introduced_In_3.90'. The latter would be automatically included in the default namespace.
The the following code would effectively roll back the compiler to before the change:
There could be an agreemeent that such transitional modules will remain for 12 months and then be removed. This would give those with a large body of purebasic code to support plenty of time to adapt, and these features would give them so many options on how best to handle the transition.
The biggest problem is all the global stuff. Especially Arrays and Linked Lists.
It would be great if there was modular support.
At the moment we have a Global Space. Inside that global space exist all of the procedures, arrays, linked lists, global variables and object cursors.
By object cursors I mean the current object being used for images, files, databases, libraries, etc.
It would be great if the global space could be replaced with a module space. All of these global objects would then be contained within a module space.
There would be a default module, which everything would be contained in by default. This would mean that existing code would work without alteration inside the default module.
If a user calls 'UseModule(module_name) then control would switch to that module. UseModule() without a name would return control to the default modele.
For example, the following code would debug 7 followed by 5:
Code: Select all
global X
x = 5
UseModule(My_Module)
x = 7
debug x
UseModule()
debug x
A command should exist for renaming modules, with settings available in the IDE. This will help to work around any name clashes that might occur.
So, for example, if both Joe and Bob have a My_HashTable Module and you want to use both the code can do this:
Code: Select all
IncludeFile(Bobs.pb)
IncludeFile(UsesBobs.pb)
IncludeFile(AlsoUsesBobs.pb)
RenameModule(My_HashTable, Bobs_HashTable)
; Everything up to this that referred to the My_HashTable is now mapped to Bobs_HashTable instead.
IncludeFile(Joes.pb)
IncludeFile(UsesJoes.pb)
IncludeFile(AlsoUsesJoes.pb)
RenameModule(My_HashTable, Bobs_HashTable)
; Everything up to this that referred to the My_HashTable is now mapped to Joes_HashTable instead.
UseModule(Bobs_HashTable)
; Work with Bobs library
UseModule(Joes_HashTable)
; Work with Joes library
Back to my library.
For example IncludeModule(Joes_HashTable) would merge both the current module and the default space. ExcludeModule(Joes_HashTable) would then remove it. Then you could do this:
An optional 'Prefix' paramater would also be useful so that if Joes_Hashtable included the linked lists AllHashes() then a call to IncludeModule(Joes_HashTable, "Joes_" would make the procedure Joes_AllHashes() available in the default space.
Taking it further, module spaces could be created for older versions of the purelibraries. For example, all the hassles brought with the memory changes to memory could have been avoided. UseModule(Default_3.81) would return behaviour for AllocateMemory and the rest to the pre-3.90 style. Old code could be wrapped just have to be wrapped in these to ensure legacy support.
Even better, their could be module like 'Removed_In_3.90' and 'Introduced_In_3.90'. The latter would be automatically included in the default namespace.
The the following code would effectively roll back the compiler to before the change:
Code: Select all
ExcludeModule(Introduced_In_3.90)
IncludeModule(Removed_In_3.90)
and