Creating modules

[peterigzParticipant]

Hello, just downloaded the latest version of Monkey2 and everything just works out of the box so far, seems like things are really coming along nicely

I’m looking to convert some modules over, but just wondering about how I should go about it in terms of organising the files. Cut a long story short, can I import just one part of a module? For example in blitzmax/monkey I could do…

Import rigz.collision

…if I just wanted to use my collision module only. Is it possible or should I be splitting things into separate module folders? Thanks!

[Mark SiblyKeymaster]

Each module is physically ‘atomic’, ie: you either import all of it or none of it.

However, each file in a module can be in it’s own namespace so you can logically split things up within a module.

So you could choose to put everything in a single ‘rigz’ module, which users would import with:

#Import “<rigz>”

Then, if they wanted to ‘use’ just the collision stuff…

Using rigz.collision

Note that the other non-collision stuff in the rigz module is still available, only users will need to fully qualify symbols, eg:

rigz.system.Blah()   ‘need this ‘coz we’re not Using rigz.system

The ‘Using’ just means they can skip the full qualification.

My advice for now would be to stick everything in one module. If you are using the lastest mx2 build, you will also need a ‘module.json’ file in the module dir that should have at least this in it:

Monkey

{ "module":"rigz" } 

1 2 3 4

{ "module":"rigz" }

 

 

 

 

 

 

 

[peterigzParticipant]

Ahh ok, that makes sense, thanks

[peterigzParticipant]

Regarding the “Modules must not have cyclic dependancies.”, in monkey I had collision.monkey, and quadtree.monkey, they both imported each other which won’t work now. So should I basically have them both in one file or is there a different way of going about it?

[Mark SiblyKeymaster]

A module is not a file – it’s a bunch of files contained in a top-level directory inside ‘modules’.

Files within a module can reference each other no problem.

This was kind of confused in monkey1 – there’s what people think of as the ‘mojo’ module that contains all the graphics, audio, input etc stuff (in mostly separate files), but there is also the mojo ‘module'(!) which is the file called ‘mojo.monkey’.

But in mx2, a module is just a bunch of related files that you stick in the same dir.

I suggest having a look at the modules/mojo folder and files to get an idea of how it works. Note that image.monkey2 can reference stuff declared in texture.monkey2, and vice versa if necessary. They don’t even have to #import each other (although they can if they want) – all the #importing of monkey2 files is done in the main mojo.monkey2 file, sort of like a ‘makefile’.

Also note that each file starts with a ‘Namespace’. This is roughly equivalent to the namespace mx1 implicitly creates for each file (or ‘module’!). But it’s way more flexible, because it’s multi-level AND has nothing to do with the actual file path, meaning you can move files around freely without breaking stuff! How I’d love to split up mojo2’s graphics.monkey file…

 

 

[peterigzParticipant]

I see, I was confusing myself where I’m just converting monkey 1 code and running each file individually to catch errors and seeing duplicate identifiers. Now I’ve moved all my imports into the main module file and everything makes sense again, I can just run the main file now and it reports errors on all the imported files (or just makemods to do the same). Thanks!

[Mark SiblyKeymaster]

seeing duplicate identifiers

Actually, that could be a bug.

Files should be able to cyclically #import each other – basically, only the first #import of a particular file actually does anything, successive #imports of the same file are ignored (in theory).

If it happens again and you can reproduce, please post some sample code!

 

 

[peterigzParticipant]

Hi Mark, this is what caused the Duplicate identifiers, simple test module:

Module name “test” with files:

test.monkey2:

Monkey

[crayon-5cb9bae218cc8270786054 inline="true" ]Namespace test.collision #Import "something" 'Types of collision Const tlBOX_COLLISION:Int = 0 Const tlCIRCLE_COLLISION:Int = 1 Const tlPOLY_COLLISION:Int = 2 Const tlLINE_COLLISION:Int = 3

1 2 3 4 5 6 7 8 9

[crayon-5cb9bae218cc8270786054 inline="true" ]Namespace test.collision   #Import "something"   'Types of collision Const tlBOX_COLLISION:Int = 0 Const tlCIRCLE_COLLISION:Int = 1 Const tlPOLY_COLLISION:Int = 2 Const tlLINE_COLLISION:Int = 3

[/crayon]

something.monkey2:

Monkey

[crayon-5cb9bae218cd3182540436 inline="true" ]Namespace test.collision #Import "test"

1 2 3

[crayon-5cb9bae218cd3182540436 inline="true" ]Namespace test.collision   #Import "test"

[/crayon]

I guess it mattered more in monkey where you could import only part of a module if you needed too so those individual imports needed to be there in each file as dependencies, but now that the whole module is imported you can organise it differently which I quite like, feels less messy.

[Mark SiblyKeymaster]

It’s a bug, will fix!

 

[Author]

Posts