This was really cool. Refactoring real code with a real worked-through and evolving solution instead of these sterile and contrived examples. Keep it up.
Very nice, I think you have a nice balance of leaving the code in a good readable shape but not perfect. There are many devs that don't know when to quit :) So you have good hand washing hygiene ( we say that in Sweden, think you understand what I am after )
Thank you for the kind words 🙏 I'd say in this video there are still a few rough edges left. You can look forward to the next video, in which I'll show my approach to the final cleanups before doing a PR. Again, not perfect, but presentable to a maintainer.
In game dev it’s not uncommon and typically much more performant to utilize switch statements instead of using a vtable to accomplish polymorphism. Sometimes this is even taken to the extremes to improve readability and usability by utilizing an enum per class or implementation and follow a pattern that is commonly called enum dispatch. When the number of classes, methods, or functions is relatively small this often outperforms the compilers generated vtable that is used to accomplish polymorphism as the access pattern is far more predictable.
Absolutely! These are trade-offs you make when you need that kind of performance. But even though this is about a small game, I still wouldn't consider the menu to be in need of such massive speeds. And if one doesn't need that speed, it would be a bad deal.
If I recall correctly, this doesn't apply here at all. If a C# class isn't declared "sealed" AND doesn't inherit from other classes, all method calls get called via a vtable. There are only a couple specific cases in C# where a vtable isn't used. Point being, a switch with enum will not help because the "Update" method call is invoked via vtable no matter what
This was really cool. Refactoring real code with a real worked-through and evolving solution instead of these sterile and contrived examples. Keep it up.
Thanks for the feedback and glad you liked it 🙏
Very nice, I think you have a nice balance of leaving the code in a good readable shape but not perfect. There are many devs that don't know when to quit :)
So you have good hand washing hygiene ( we say that in Sweden, think you understand what I am after )
Thank you for the kind words 🙏 I'd say in this video there are still a few rough edges left. You can look forward to the next video, in which I'll show my approach to the final cleanups before doing a PR. Again, not perfect, but presentable to a maintainer.
In game dev it’s not uncommon and typically much more performant to utilize switch statements instead of using a vtable to accomplish polymorphism. Sometimes this is even taken to the extremes to improve readability and usability by utilizing an enum per class or implementation and follow a pattern that is commonly called enum dispatch. When the number of classes, methods, or functions is relatively small this often outperforms the compilers generated vtable that is used to accomplish polymorphism as the access pattern is far more predictable.
Absolutely! These are trade-offs you make when you need that kind of performance. But even though this is about a small game, I still wouldn't consider the menu to be in need of such massive speeds. And if one doesn't need that speed, it would be a bad deal.
If I recall correctly, this doesn't apply here at all. If a C# class isn't declared "sealed" AND doesn't inherit from other classes, all method calls get called via a vtable. There are only a couple specific cases in C# where a vtable isn't used.
Point being, a switch with enum will not help because the "Update" method call is invoked via vtable no matter what