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
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: