When I first saw the new version of the Distribution Center Discrete Event Simulator example model, I was surprised by the note at the top of the module file “the main file that includes this one must have both the csv and time extensions”.
Now, it turns out that declaring extensions in a module file is not even allowed.
This definitely breaks the idea of modularity!
If a module relies on an extension, it must be able to declare so itself.
Normally, it would be no business of the model which extensions are used by the module.
I understand that this could lead to duplicate declarations if the main model uses the same extensions.
But, please, solve this by checking for repeated declarations instead of forbidding using extensions in modules.
The concern is not with duplicate declarations, but rather with the flexibility of extensions compared to modules. In the current extension ecosystem, including an extension can change the user’s environment in arbitrarily complex ways, including adding primitives to the language, adding menus and other GUI elements, and executing system-level code. Since the module system is only intended for creating helper procedures in NetLogo code, allowing the use of extensions in modules would far exceed the intended scope of the system. In the case of the model you mentioned, including the extensions in the model itself ensures that the user knows which extensions are being included and can give explicit permission for those extensions to be loaded.
Sorry to be the bearer of bad news, but hopefully this reasoning is understandable. If there is specific functionality that would be important for you to have in a module, let us know and we can look into ways to provide that within the scope of the module system.
No need to apologize. I regard this as explanation rather than bad news. And it inspires creativity…
Interesting to know how much power extensions have. I did not realize the full extent of what is possible with extensions.
So, the reason for the current mechanism is more of a technical nature than a conceptual choice.
On the technical side, I understand the problem.
From a conceptual point of view, I think there are other options, still.
I will close this topic now, and move any further discussion to a new topic.