-
Notifications
You must be signed in to change notification settings - Fork 5
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
Eliminate IOType.fromCoreType #273
Comments
To make sure I didn't miss any use cases, I instrumented
|
Some notes from this issue: TODO: Because serialization involves accessing if it has either toStateObject or stateSchema, then it must have both if it has toStateObject, it must have fromStateObject | applyState | { |
Reopening. Changes like this one in natural-selection violate PhET naming conventions. - Bunny.BunnyIO = IOType.fromCoreType( 'BunnyIO', Bunny );
+ applyState: ( t, s ) => t.applyState( s ), Abbreviated names are discouraged, especially names like I have a hunch that this is what it should be, but I'd have to dig around to be sure:
@samreid you did |
@samreid I see similar naming violations for |
Good idea, I improved the parameter names in the commits. Please let me know if I missed any. |
Did you mean to assign this to me for review? I took a peek, looks like you got them all. Feel free to close. |
From #263, I would like to eliminate IOType.fromCoreType. It was introduced as a convenience method, but it is making the type checking very complex and difficult, and making it difficult to make progress in classifying the different state serialization types.
We also now have well-established patterns and examples and type checking, so using the
IOType
constructor can be used safely. And it will be nice to have one way of doing things instead of two.The text was updated successfully, but these errors were encountered: