defineEvent and defineInit?

Question

defineEvent and defineInit?

achubaty opened this issue 8 years ago · 8 comments

Is it worth restructuring modules to hide the doEvent.modulename and associated if/else contructs and use a defineEvent function instead?

That makes the module structure MUCH simpler, and makes adding a new event very easy: just add a new defineEvent anywhere in the file.

We can do something similar for the .inputObjects piece with a defineInit.

This would be a major structural change but would make module creation vastly easier for the user/developer.

Answer 1 · 2016-10-14T19:09:25.000Z

Interesting. Could be good. A couple potential problems:

If they are scattered all over, it is hard to organize them. We would likely need a few methods for helping to organize the events. That would be doable. We can also structure the moduleTemplate in a compact way.
Others?

Answer 2 · 2016-11-24T22:22:18.000Z

Thinking about this more, implementing defineEvent may solve the namespacing issue (#292, #294).

If defineEvent() returns an object (environment?) that contains the module's event functions and doEvent.moduleName(), then we avoid function name collisions. This environment would be stored in the sim@.envir. We just need to tweak the way functions are called within a module -- using sim$function() could automatically redirect much like P(sim) does (i.e., automatically getting the module name).

Does this make sense?

Answer 3 · 2016-11-24T22:28:19.000Z

In other words it provides a mechanism to "nest" the contents of sim@.envir, so instead of this:

sim$doEvent.module1Name()
sim$module1NameEvent1Name()
sim$module1NameEvent2Name()
sim$module1NameEvent3Name()

sim$doEvent.module2Name()
sim$module2NameEvent1Name()
sim$module2NameEvent2Name()
sim$module2NameEvent3Name()

sim$doEvent.module3Name()
sim$module3NameEvent1Name()
sim$module3NameEvent2Name()
sim$module3NameEvent3Name()

we get this:

sim$module1$doEvent()
sim$module1$Event1Name()
sim$module1$Event2Name()
sim$module1$Event3Name()

sim$module2$doEvent()
sim$module2$Event1Name()
sim$module2$Event2Name()
sim$module2$Event3Name()

sim$module3$doEvent()
sim$module3$Event1Name()
sim$module3$Event2Name()
sim$module3$Event3Name()

Answer 4 · 2016-11-24T23:01:41.000Z

Yes. This works.

We can genericize the approach used in P(sim) to extract the current module.

Answer 5 · 2016-11-24T23:35:15.000Z

I've started a new feature branch for this (316-defineEvent)

Answer 6 · 2016-11-30T22:28:55.000Z

made progress implementisng namespacing for module functions by redefining $ and [[ on simLists to store objects in a separate environment for each module (sim@.envir$moduleName). this is implemented such that objects defined as module inputs/outputs are put in the sim@.envir, whereas all other module objects are in sim@.envir$moduleName.

no changes are needed to module code, but see note re: use of ls() etc. (#324 (comment))

still to do: implement the defineEvent function.

Answer 7 · 2017-03-22T21:54:40.000Z

take a look at the modules package: https://cran.r-project.org/web/packages/modules/vignettes/modulesInR.html

Answer 8 · 2018-01-25T23:37:13.000Z

This issue was moved to PredictiveEcology/SpaDES.core#19