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

Deprecation mechanism for sections or keywords #64

Open
robertodr opened this issue Mar 29, 2019 · 4 comments
Open

Deprecation mechanism for sections or keywords #64

robertodr opened this issue Mar 29, 2019 · 4 comments
Assignees
Labels
enhancement New feature or request lowprio Low priority stuff RFC Planning and design discussions
Milestone

Comments

@robertodr
Copy link
Contributor

Some programs allow different names to be used for the same keywod/section. For example, CONVTHR might be just as valid as CONVERGENCE_THRESHOLD (or something similar). Do we want to allow for this, and if yes how would it look? An alias field accepting a list of aliases?

@robertodr robertodr added enhancement New feature or request RFC Planning and design discussions labels Mar 29, 2019
@bast
Copy link
Member

bast commented Mar 29, 2019

My first reaction was very skeptical.

But after some more thinking: this would be a great mechanism to deprecate keywords. Keyword deprecation is something that we should consider - every code and every input needs that.

@robertodr
Copy link
Contributor Author

How would deprecation look? A boolean field that emits a warning if set? Or a multiline string? The latter would allow to actually document what to do to avoid the warning...

@bast
Copy link
Member

bast commented Mar 30, 2019

A multi-line string. But perhaps we should open a new issue on deprecation? Since this can be implemented independently of whether there are aliases or not. Although it could go together.

Deprecation is something that many codes simply do not do or do not do well at the frustration of the user who is often 1-2 years behind the developers with inherited input examples. It would also make it easier for developers to change things without being held too tight by backwards compatibility.

@bast bast changed the title Keyword/section names aliases Deprecation mechanism for sections or keywords Jul 18, 2019
@bast bast added the lowprio Low priority stuff label Jul 18, 2019
@bast
Copy link
Member

bast commented Jul 18, 2019

For the deprecation we need a new field or fields (like "warning" or "error", but we did not conclude on this) which would become function calls in the generated parser and display deprecation warnings or errors to the user.

We postpone this until the rest of the code solidifies a bit.

@robertodr robertodr added this to the v1.0.0 milestone Aug 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lowprio Low priority stuff RFC Planning and design discussions
Projects
None yet
Development

No branches or pull requests

2 participants