`Create()` and `Read()` to be Virtual instead of Abstract?

[alelom]

I see the point of having Create() and Read() as abstract.

In theory, that forces developers in sticking to the "Replace" or CRUD paradigm, or at least to give a thought to that.

However:

1. I think that in practice this is not true. You still need developers to read the Wiki to know how to properly implement and use the CRUD methods.

2. In a way, I think that enforcing the implementation of Create() and Read() is giving a false sense of compliance. People still can (and will) just implement empty methods.

3. It does not allow for flexibility. There are Toolkits where it does not make sense to enforce the "Replace" or CRUD paradigm. DataViz_Toolkit, GitHub_Toolkit, MachineLearning_Toolkit, Sharepoint_Toolkit, and the list goes on. Those toolkits are forced in implementing empty Create and Read methods, while they sometimes implement the "non mandatory" CRUD methods (Delete, etc).

4. It conflicts with the fact that we give the possibility to override the Push. If you override the Push, nothing stops you to avoid using the Create and Read, which happens for all Toolkits at point 3. People just put empty Create and Read methods overrides in their Toolkits.

Proposal

• Make Create() and Read() as virtual methods.
• Be clearer with the comments in the body of the parent BHoM_Adapter for the usage/implementation of those CRUD methods. What we have now with Level 1 - Always required and Level 2 - Optional is good but we can elaborate a bit more.
• "Sponsor" more the BHoM_Toolkit template, which should contain enough comments and links to the Wiki to set on the right track new developers.

@adecler @al-fisher @IsakNaslundBh @epignatelli @rwemay

[IsakNaslundBh]

Could argue both ways here, and the Template solves much of the reason for forcing implementation by making read and create abstract. That being said, I think it still can be useful to keep them, if for nothing else, to direct the intended default workflow of the adapter.

I do not really agree with it being a conflict of push/pull being override-able and create/read abstract. Abstract -> intended use, virtual -> you are still free to do whatever you want.

To me this is not a big thing though. If I had to choose I would probably keep them abstract to highlight their significance in the intend work of the adapter, but not too bothered if we make them virtual.

[adecler]

I agree with Isak.

[alelom]

This has been closed by #151