MRC-CSO-SPHSU / LoneParentsModel.jl

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

factor out generic parts of person.jl #90

Open mhinsch opened 2 years ago

mhinsch commented 2 years ago

The helper functions should be in a separate file so that different person types can reuse them.

AtiyahElsheikh commented 2 years ago

What I was referring to is that another way of constructing Person-types could be

mutable struct Person # for demography simulation 
... # Just kinship & basicInfo 
end 
.. 
mutable struct PerEconomy # for econmiy simulations  
  person::Person
  income:: 
  ... 
end 

This is just an option. But the question, if this makes development easier / or difficult

mhinsch commented 2 years ago

Ah, I think I see what you mean now, so basically that would mimic OOP subclassing, wouldn't it?

I think in the end that wouldn't save any effort, though, since all methods operating on Person (including the ones that are forwarded from Kinship and Basicinfo) would have to be forwarded to PerEconomy. When you are doing that you might just as well forward them directly from e.g. Kinship to PerEconomy (same amount of code).

In my opinion this is really a rare case where copy and paste is a valid development method. When a new Person type is needed just copy person.jl (or whatever other person type is closest to what you need) and add and remove forwarding/component declarations as needed. Most (ideally all) code in person.jl is purely administrative anyway, in the sense that it doesn't actually do anything but only constructs types and redirects method calls. Therefore the risk of making hidden semantic mistakes when doing a simple copy-paste-edit is pretty low.

That said, I think the current way of dealing with agent components is usable, but not great. I just haven't been able to come up with a better way so far.