Use enums for Modes and RawModes in C#8510
Use enums for Modes and RawModes in C#8510Yay295 wants to merge 63 commits intopython-pillow:mainfrom
Conversation
Structs have better type safety, but they make allocation more difficult, especially when we have multiple Python modules trying to share the same code.
this is necessary to have python/typeshed#12791
|
|
||
| typedef struct { | ||
| const char *const name; | ||
| } ModeData; |
There was a problem hiding this comment.
You've created a struct with only one member, presumably because you expect to add more members in the future. Are you trying to prepare for #6547?
There was a problem hiding this comment.
There are some things I think could be added to this struct in the future, but the more important reason for this as it is right now is type safety. A char * could be almost anything, but a ModeData can only be a ModeData.
There was a problem hiding this comment.
Correct me if I'm wrong, but the only place where ModeData is returned is from Mode.c's getModeData() (and similarly, RawModeData from getRawModeData())? It's used there, and in the construction of the MODES array in Mode.c, and by design, never anywhere else? I don't think we even pass between ModeData between functions - every use outside of Mode.c is just to access the name.
So the only benefit is to assure us that getModeData() and getRawModeData() return the correct output? This could just be my opinion, but I think they are simple functions, and it's overkill to be passing around a struct to the rest of the C code to ensure their correctness.
There was a problem hiding this comment.
I think this will be useful for the band names and arrow band format constants as well. I could also see this as where the bands/depth/type are stored.
|
This has been rebased as #9100 |
3 participants
Adds some type safety when comparing modes, and replaces a lot of string comparisons with enum comparisons.