You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have just starting using this package and am really enjoying it! However, I have noticed methods are named inconsistently (some with camelCase, some with snake_case). Since this is a JavaScript package, I would propose using camelCase for all method, function, or variable names. The old snake_case names can be deprecated and aliased to the camelCase names without causing any breaking changes. If it would be helpful, I can make a PR for this.
The text was updated successfully, but these errors were encountered:
Thanks @joshunrau. I'm not opposed to making the switch; my only concern is that there is 10 years worth of content (docs, recorded talks, etc.) that uses snake case for timeline/trial parameters. Since many researchers get introduced to JS programming through this library, the disconnect between existing docs might be especially confusing. But, if everything is aliased and there's deprecation warnings it seems like the trade off is probably worth it.
@jspsych/core any thoughts?
I think if there are no objections, then a PR would be very helpful.
Awesome! I am hoping to make a lot of contributions to this project since I think it could be really nicely integrated into what we are doing (Open Data Capture).
I have just starting using this package and am really enjoying it! However, I have noticed methods are named inconsistently (some with camelCase, some with snake_case). Since this is a JavaScript package, I would propose using camelCase for all method, function, or variable names. The old snake_case names can be deprecated and aliased to the camelCase names without causing any breaking changes. If it would be helpful, I can make a PR for this.
The text was updated successfully, but these errors were encountered: