You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In GAP, there seem to be 3 main ways we alter the behaviour of a function:
Passing additional optional arguments, as in InstallPackage("digraphs", true)
Using the option stack, as in InstallPackage("digraphs" : keepDirectory)
Passing an options record, as in Test("myfile.tst", rec(width := 90, rewriteToFile := true))
Unfortunately, the package manager has got itself into a state where it's doing both 1 and 2 for different things, as shown above. I want to nip this in the bud and come up with something consistent. My thoughts are:
Optional arguments are awkward when we start adding more and more fields. Already version and interactive are only distinguishable because they have different types, and it's getting messy handling them.
The option stack has nice syntax and obvious names, and I'm leaning towards this being the "right" way. But is there any weird behaviour I should worry about?
Options records are foolproof – this would be my second preference.
I plan to pick just one mechanism now and refactor the package to use it, either removing or deprecating other things that already exist. This might fit well with an overall transition to a more sane codebase and a 2.0 release where I fix some other stuff.
Is there any reason not to switch to using the options stack?
The text was updated successfully, but these errors were encountered:
mtorpey
added
the
discussion
Not exactly an issue to be resolved, but a discussion about the future of the package
label
Sep 3, 2024
Options stack: just be aware that if you go into an error break loop and exit that the options stack is not reset. That can sometimes lead to weird experiences.
Regarding "breaking changes", I would recommend against them unless it is really awkward to support the old syntax -- you can remove it from documentation, or even print an InfoWarning that it is deprecated, but at least you won't break existing code.
Regarding the options stack, this seems like a serious consideration. On the one hand I love the options syntax and the way options propagate to helper functions automatically. But that non-reset stack is certainly weird, and could surprise users. Do you have a view on whether this would be a good idea?
I'll note that comment about breaking changes. Things aren't too bad yet, and it should be very possible to preserve things like InstallPackage("name", false);
In GAP, there seem to be 3 main ways we alter the behaviour of a function:
InstallPackage("digraphs", true)
InstallPackage("digraphs" : keepDirectory)
Test("myfile.tst", rec(width := 90, rewriteToFile := true))
Unfortunately, the package manager has got itself into a state where it's doing both 1 and 2 for different things, as shown above. I want to nip this in the bud and come up with something consistent. My thoughts are:
version
andinteractive
are only distinguishable because they have different types, and it's getting messy handling them.I plan to pick just one mechanism now and refactor the package to use it, either removing or deprecating other things that already exist. This might fit well with an overall transition to a more sane codebase and a 2.0 release where I fix some other stuff.
Is there any reason not to switch to using the options stack?
The text was updated successfully, but these errors were encountered: