Now with the preview of the new module system, I went back to my feature request for modularity (https://forum.netlogo.org/t/modularity/801). One of the underlying ideas is that sub-models in ABM should be put in their own modules. This would typically mean that different types of agents (breed in NetLogo) would live in their own source files.
In order to see how far this idea is supported with the current module system, I reworked the Paths model from the Models Library.
Admittedly, even if the expected functionality had been there, the example only would perform technical encapsulation of the breeds. Conceptually, this is not a good example of modularity at all!
Unfortunately, the first step was unsuccessful already. It is not allowed to define a breed in a module.
I hope this restriction (and some similar ones) will be relaxed in future versions of the module system.
Because the idea did not work out well with the module system, I proceeded using the old include files (which I had never used for this purpose yet).
In include files, it is allowed to define breeds and breeds-own variables, and many other things that would definitely break encapsulation.
The model file and include files below simulate encapsulation, by only using procedures from the include file in the main model file.
The corresponding import lines are just below the __includes line, but commented out.
The modules files as I had intended them are almost identical to the include files, only adding an export line.
The main model file is PathsX.nlogo, the module files have been renamed .nlm.txt for getting them unto this platform.
buildings-module.nlm.txt (247 Bytes)
walkers-module.nls (432 Bytes)
walkers-module.nlm.txt (491 Bytes)
PathsX.nlogox (49.5 KB)
buildings-module.nls (195 Bytes)
Would it be a big problem if breed, breeds-own, and similar constructs are allowed in module files?
This would bring the idea of encapsulation a large step forward.