defineEvent and defineInit? about spades.core HOT 8 CLOSED

From @eliotmcintire on October 14, 2016 19:9

Interesting. Could be good. A couple potential problems:

1. 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.
2. Others?

from spades.core.

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 [email protected]. 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?

from spades.core.

In other words it provides a mechanism to "nest" the contents of [email protected], 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()

from spades.core.

From @eliotmcintire on November 24, 2016 23:1

Yes. This works.

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

from spades.core.

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

from spades.core.

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

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

still to do: implement the defineEvent function.

from spades.core.

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

from spades.core.

Closing, low priority. Labelled "NotDone"

from spades.core.