https://github.com/PredictiveEcology/SpaDES.core/blob/b2ca257d659e3b7ed4996c777d2add7f63398ee8/R/copy.R#L85
To reproduce problem with debugging, checkout SpaDES.core@ShowEnvironmentError
devtools::test(filter = "checkpoint$")That will open a browser() call and then the next 5 lines or so can be run interactively... the all.equal is TRUE, then change the environment and it goes all weird.
I'm not sure I like the solution to this name collision issue. I'm posting the example here instead of scfm because it could happen with anything, really. In this case, one object (from scfm) is a spatialPolygonsDataFrame, and the other is a list (whatever Tati was referring to, presumably fireSense_dataPrep). I'm not sure why she needs both objects in the sim list, but that's irrelevant. In this case, the fix was this:
if (is(sim$firePoints, "list")){
tmp <- do.call(what = bind, args = list(sim$firePoints))
} else {
tmp <- sim$firePoints
}
# sim$firePoints <- tmp # TM ~ Terrible terrible idea. Other modules might use this object and
# espect it to be the list of fire points
# You shouldn't modify it unless its a dataPrep module or smth and even so, its dangerous.
# Just use your local variable, or save as a new sim.Object if this needs to go across modules.
# I checked all SCFM modules, and only regime uses firePoints, so I am keeping the local
# Object
#several lines later
# firePolys <- unlist(sim$firePoints) # TM ~ Use tmp, as its already unlisted!
firePolys <- tmp # TM ~ Use tmp, as its already unlisted!sim$firePoints could be anything supplied by another module, including objects that can't be coerced into something usable by 'scfm', unlike in this example. So while the workaround is correct, I don't think the code that does this should happen in scfm. A user who only uses scfm might wonder "why can firePoints be a list if the metadata stipulates SPDF, and the module supplies an SPDF". It feels like an integration module should be used instead, but this is tricky because presumably both modules using 'sim$firePoints' are parameterization modules that need it during some init event. So whatever integration module is created, it would have to schedule this conversion to happen in between the two init events. But either way it is an idiosyncratic integration issue that belongs in an idiosyncratic integration module. And even that doesn't resolve the general problem of having two completely irreconcilable objects with the same name. That's my take anyway.
