Allowing for derived Cell objects, defined by cell types #153
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I had proposed a PR some time ago already around this idea, but then I wasn't sure it was so important and it ended up being closed.
With the new implementation of PhysiMESS, I wanted to revive it, as I think it will enable things which are not possible otherwise (mostly at destruction), and simplify our life a lot for designing extensions of the Cell class.
The idea is that for PhysiMESS (and possibly other addons) we need to add new variables to the Cell. We can do this by having our own data structure, like :
which is how I defined it for now. And it works, you have to initialize it after cell instantiation, and it's not so bad. But at deletion it's a problem, because we can never clean it at the exact same time as the Cell deletion.
But with derived class, we would have our own constructor/destructors, so it would simplify instantiation and would allow proper destruction.
Also, important to note, it's a non-breaking change, everything would keep working the same way as before for those who don't want to use derived classes of Cell.
The basic workflow would be the following : First, we defined our specialized class. Here I won't go into details, you get the idea.
Then we need to be sure that at cell creation, we are instantiating the proper Class. To do this, we create new custom functions, and we assign them to a function pointer in the Cell_Functions class, depending on the cell type
Then, either in setup_tissue, or in load_cells_from_pugixml, when we would use
it would automatically call the proper constructor via the instantiate_cell function pointer defined in the cell's definition Cell_Functions class. If this function pointer is NULL, then it will call a standard one.
The way it works is that create_cell will now have an optional argument, which is a function pointer to an instantiate functions :
So the old create_cell() will still work and create a default_cell, but if we want a custom function we can put it as argument.
And create_cell(Cell_Definition) can now use it :
At division, we would instantiate the daughter cell using the same instantiation function of the mother cell :
And last detail, to make sure that at destruction of our Cell* the potential derived destructor is called, we need to declare the Cell destructor as virtual, as well as the Basic_Agent destructor.
Let me know what you think ! I will probably write a new PhysiMESS version with this addition next month, to be able to have the example of the two approaches, which will probably help the discussion.