MRC-CSO-SPHSU / LoneParentsModel.jl

An initial implementation of an ABM for social and child care
0 stars 4 forks source link

What does *M stand for? #38

Closed AtiyahElsheikh closed 2 years ago

AtiyahElsheikh commented 2 years ago

e.g. KinshipM and BasicInfoM Module?

If this is the case, to my understanding you'd like to re-structure the code into more modules, e.g. Module Person. In this case, the naming convention would be enough to deduce if a file corresponds to a module or not.

Edit: Yes in this case, the module name should be different than the type name

mhinsch commented 2 years ago

It's quite annoying, but modules live in the same namespace as everything else, so sadly we have to find a way to systematically name types and modules differently. I'm not sure whether Person should be a module or not. My thinking was that Kinship and BasicInfo are reusable building blocks so they should definitely be modules. Person isn't, so it doesn't have to be and it's more a question of preference.

AtiyahElsheikh commented 2 years ago

so Person.jl can change to person.jl (so now we know it is just a type) However, (I am not sure at the moment) I suspect that I will need the module name to be identical to the file name, e.g. KinshipMod.jl (Mod would be more obvious). Would you propose to place KinshipMod & BasicInfoMod.jl outside xagents? or Alternatively (type name to have KinshipBlock, BasicInfoBlock ? (I like this better and hence rename the files to Kinship.jl and BasicInfo.jl) Also What could be a super module name, e.g. BuildingBlocks.jl? (Rather than XAgents.KinshipMod or Xagents.Kinship). There will be more and more modules. There is a need to organize them as submodules.

mhinsch commented 2 years ago
AtiyahElsheikh commented 2 years ago

So we reached two proposal concerning the last point:

  1. typical structure, say to introduce the module XAgents.AgentModules.Kinship or AgentModules.Kinship within agent_modules/Kinship.jl (I have the impression that this is straightforward and better for interactive usage from REPL and unit testings)

  2. just to leave independent modules here and there, leave them where they are and have push!(LOAD_PATH,) and remove!(LOAD_PATH,) here and there