As Cherab has expanded and we have started to add ionisation rates, a name clash has occurred between the process of ionisation and the ionisation level of an ion. It has been suggested that this clash be resolved by referring to an ion's charge (charge state) in the API rather than it's ionisation (ionisation level). This would result in substantial changes across the Cherab API, however it would reduce potential for user confusion going forward.
This is a large change and will need to be carefully managed. Managing this change can be done with good feedback to the user:
Where ionisation is currently used as a class attribute or in method calls, we would replace it with charge. The ionisation attribute will remain for one release, but using it will result in an exception being raised that informs the user that they need to update their code/scripts to use the new name.
Another option is to raise a deprecated warning first and then remove the ionisation support in a later release, but this would require supporting two code paths in parallel for a release and therefore a greater risk of mistakes.
The first option is my preferred solution at his stage of development.
As Cherab has expanded and we have started to add ionisation rates, a name clash has occurred between the process of ionisation and the ionisation level of an ion. It has been suggested that this clash be resolved by referring to an ion's charge (charge state) in the API rather than it's ionisation (ionisation level). This would result in substantial changes across the Cherab API, however it would reduce potential for user confusion going forward.
This is a large change and will need to be carefully managed. Managing this change can be done with good feedback to the user:
Where ionisation is currently used as a class attribute or in method calls, we would replace it with charge. The ionisation attribute will remain for one release, but using it will result in an exception being raised that informs the user that they need to update their code/scripts to use the new name.
Another option is to raise a deprecated warning first and then remove the ionisation support in a later release, but this would require supporting two code paths in parallel for a release and therefore a greater risk of mistakes.
The first option is my preferred solution at his stage of development.