Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate inheritance hierarchies for mutation and gamete #100

Open
molpopgen opened this issue Mar 18, 2018 · 2 comments
Open

Eliminate inheritance hierarchies for mutation and gamete #100

molpopgen opened this issue Mar 18, 2018 · 2 comments

Comments

@molpopgen
Copy link
Owner

The current inheritance hierarchies for these types were originally developed so that fwdpp could use static_assert to enforce concepts via std::is_base_of.

Given that the library does not (easily) support population w/multiple mutation types at run time (although the current pop types do indeed allow for that), inheritance hierarchies should be removed and the library should rely on compile-time "duck typing" based on a minimal set of requirements to define a mutation.

The same arguments apply to the concept of "gamete".

@molpopgen
Copy link
Owner Author

Side effects include:

  1. Undoing tuple-based constructors introduced in Construct types with tuples #59 and construct gametes from tuples #62. That's fine, as these changes can be viewed as a feature-creep caused by stuff I wanted in fwdpy11, but that can be done there via a different mechanism.

  2. Assignment of the neutral field would have to be handled differently, as we could no longer rely on dispatch to the base class. Again, easy enough.

  3. The popgenmut size would shrink by 8 bytes, which is cool!

  4. The design of the changes being introduced in Infinite site mutation #95 may no longer be desirable. Rather, it would be preferable to model those concepts over what was done in Refactor serialization code to use argument-dependent lookup (ADL). #90, and use ADL instead of member functions.

@molpopgen
Copy link
Owner Author

Useful to note that doing this would pre-adapt the library for C++20's "concepts".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant