What does *M stand for?

[AtiyahElsheikh]

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]

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]

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]

• Agreed re Person.jl -> person.jl.
• Yes, I think the module needs to have the same name as the file (unless you want to manually include() and then import).
• +1 for *Block instead of *Mod(.jl)
• Concerning the organisation - I don't see why we need a module to put them together. In my opinion it would be totally fine to have them in a separate directory (e.g. agent_modules) and import them directly where needed. As far as I can see the only point of XAgents is anyway to put together bits that are not in modules and are just included.

[AtiyahElsheikh]

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