New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shader generators are converted to modules #5552
Conversation
const particle = { | ||
generateKey: function (options) { | ||
class ShaderGeneratorParticle extends ShaderGenerator { | ||
generateKey(options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these generateKey functions be static? If all functions on these classes were static, no need to create instances. Just export the classes directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
standard.js contains some members as well .. I'm not sure I'd want to change those and all functions in it to static, instances seems more flexible for the future too.
|
||
const basic = { | ||
generateKey: function (options) { | ||
class ShaderGeneratorBasic extends ShaderGenerator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of this extends?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To give all those classes base class / shared type information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see that used anywhere?
The structure of this whole class hierarchy is very non-standard (and for me confusing).
ShaderGenerator isn't a real base class because it defines no base functionality. Rather it is a set of static helper functions.
Then ShaderGeneratorBasic and the rest implement what looks like a consistent set of functions (which presumably program-libraray expects, but never defines).
Ultimately the structure/interface of ShaderGenerator isn't defined anywhere and is left as implicit.
I don't think there needs to be any inheritance here and probably program-library should define what structure a 'generator' takes. Each implementation of generator just implements that interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some point I'm going to add type information to the program-library, and this is the type of the generator. Ideally this would be an interface, but unfortunately JS does not have a concept of this. But this is the only way to assign a single (base) type to multiple classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If program-library just uses duck typing on generators, why do generators need a class hierarchy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some JSDocs to the program-libray that use the base class type - type safety is where we're going to with the engine changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving under the assumption this mess is cleaned up in future :)
ShaderGenerator
, implements functionality from now deletedcommon.js
as static functions (so that they can be called from outside of generators too)