Add additional traits and methods to DeprecatedSyscallSelector

[THenry14]

Implements #10

Introduced changes

• add missing traits and methods to DeprecatedSyscallSelector

Checklist

• Linked relevant issue
• Updated relevant documentation
• Added relevant tests
• Performed self-review of the code
• Added changes to CHANGELOG.md

[ksew1]

What do you think about using the strum crate for this? We could then just use its derives instead of writing this code.

[THenry14]

What do you think about using the strum crate for this? We could then just use its derives instead of writing this code.

I thought about it to be honest, even started the implementation. I then figured that maybe it is not really worth it the additional dependency to only do this for one enum. I'm not strong on that opinion though, so if you like this better let me know and I can change it.

One general thing though - I am actually thinking about refactoring this enum completely, as it's not really fit for purpose at the moment. I have vague plans to split it into syscalls and libfuncs, which would allow to get rid of fromstr and tostr traits. But this work is not yet planned completely, for now I hold it in an issue in the profiler's triage. Will open an issue/PR here when it's needed/planned.

[ksew1]

What do you think about using the strum crate for this? We could then just use its derives instead of writing this code.

I thought about it to be honest, even started the implementation. I then figured that maybe it is not really worth it the additional dependency to only do this for one enum. I'm not strong on that opinion though, so if you like this better let me know and I can change it.

One general thing though - I am actually thinking about refactoring this enum completely, as it's not really fit for purpose at the moment. I have vague plans to split it into syscalls and libfuncs, which would allow to get rid of fromstr and tostr traits. But this work is not yet planned completely, for now I hold it in an issue in the profiler's triage. Will open an issue/PR here when it's needed/planned.

We are already dragging a lot of dependencies through cairo-lang-*. My only concern is that when we add some variant, we need to add it in three places instead of just one. I would personally go with strum

[THenry14]

What do you think about using the strum crate for this? We could then just use its derives instead of writing this code.

I thought about it to be honest, even started the implementation. I then figured that maybe it is not really worth it the additional dependency to only do this for one enum. I'm not strong on that opinion though, so if you like this better let me know and I can change it.
One general thing though - I am actually thinking about refactoring this enum completely, as it's not really fit for purpose at the moment. I have vague plans to split it into syscalls and libfuncs, which would allow to get rid of fromstr and tostr traits. But this work is not yet planned completely, for now I hold it in an issue in the profiler's triage. Will open an issue/PR here when it's needed/planned.

We are already dragging a lot of dependencies through cairo-lang-*. My only concern is that when we add some variant, we need to add it in three places instead of just one. I would personally go with strum

Sure, makes sense. Made the change and tested it against the profiler code, everything seems to be working 👍

[ksew1]

Don't want to block you 😅. Please only address my comment