NewsForumsCodeLogsGallerySpecsSearch

How do you use Modules,Classes, Files & Folders?

Monkey Forums/Monkey Programming/How do you use Modules,Classes, Files & Folders?

Tibit(Posted 2012) [#1]
Idea: Improve Monkey Module Concept

I wanted to start a discussion on it to see what others think, the current system is not bad, I just felt it could use a slight rework :)

Problem: Module concept is confusing!
Solution: Let us call Files for Files and the folders in the /modules/ folder for Modules.

Problem: Inconsitency - A folder in the /modules/ folder is a module, but anywhere else a module is a file
Solution: a folder is (by default) a module.
Note: This is exactly how the /modules/ folder work. Is there a reason this can't work outside the modules folder also?

Problem: Programmers that put one Class per File don't get the benefits of the current Module system and need to "work around it"
Solution: import can handle folders - i.e import a folder = import all .monkey files in that folder

Problem: Importing a "folder" a "module" a "file" has the same import syntax - name conflicts arise
Solution: Assume folderName in import, if import ends with .monkey then assume the file is a module

Problem: Importing a module (that is a file) does not import sub-folders
Solution: Importing a folder also imports sub-folders.

Problem (If changed): Some frameworks and games use the "current" file-module based system with import files that import files and some users might prefer this
Solution: Importing a file (ending with .monkey) works as current system and anyone who prefers the current way of things can still with the slight change of adding .monkey keep doing that
Note: Alternative would be to have .monkey as and use * like in the reflection filter, but the question is which do people really use the most?

Problem: Some frameworks (like diddy and more) has examples and module-code, however I can't put diddyTrunk in my modules folder because then it won't import! Creating administration each update.
Solution: Allow users to add extra relative /modules/ folders (like in monkey_ext).
Example:
[monkeycode]#ModuleSource+="./././diddyBase/source/diddy"
import testModule[/monkeycode]

Problem: Inconsitency - Reflection filter, LoadImage, SaveState, Imports all use different syntax.
Solution: Let the new improved import syntax use the file & reflection import syntax (For Example module:// as per default)
+Benefit: Users can now import files,images,sounds from any module + any custom added /modules/ folder into their game easily

Problem: It can be difficult to handle a module that req another module and so on, if an older version is req this can create import conflicts
Solution: If imports import folders and subfolders, then just dump any req into the modules subfolder and that module will use that
Note: For this to work flawlessly we might need private imports - Imports that can't be seen/used from outside that module/sub-module

Problem: Modules can be scattered across network drives, internet, more, but needs to be copied in the modules folder each monkey release - and this might also apply to future user made targets and modules!
Solution: Adding an external module can be done through the IDE. There is a setting managed by the IDE that keeps track of modules and supplies this to trans. All modules added like this will appear to reside in the /modules/ folder - that is it works directly with "import myModule".

Problem: Assets like maps,art and sound req a lot of manual file management - especially when setting up new projects
Problem: Resource handling code across frameworks is usually not compatible
Problem: Using TexturePacker or an external FontLibraries can't easily be interchanged
Problem: Assets are loosly typed, you get runtime crash instead of compile warning
Problem: You can only have one DataFolder and it must be called /data/
Solution: A module can contain resources
[monkeycode]
import graphics.starships.*images into art ' Import all my starships for instant access - will be copied to build folder
import graphics.bullets.rocket.png 'import specific image, handle = rocket

'into command means I get a art.monkey file generated with handles for each file based on that file's name
'So instead of loosly typed "myship.png", I can use art.myship (import into handler art). Or if we would not use "into" then we would use each image's name as handle

'On Create
LoadImage art ' loads all those starships in my art handler, same would apply to other types data, frameworks can have great use of this
' art is a File(module) and a class
LoadImage rocket' loads specific image (note no quotes are req)

' In Render
DrawImage art.ship1, X,Y ' render if loaded, else render a white-rect with same rotation
DrawImage art.ship2, X,Y
DrawImage art.ship3, X,Y
DrawImage rocket, X,Y
Local itIsJustAString:String = rocket
DrawImage itIsJustAString, X,Y
[/monkeycode] Note: This one might be pushing it. Idea was to bring more consistency to all file-handling things so they all use similar syntax and that might create some cool benefits like this.