Remove prototype functions

Our fundamental math types (Cartesian, matrices, quaternions, etc.) have prototype and non-prototype functions, e.g., u.add(v) and Cartesian3.add(u, v).

I think I advocated, perhaps even insisted on this at some point. However, after maintaining and using these types, including using them from web workers, I’d like us to drop the prototype versions. They are redundant, more code to doc, more code to test, more API for users to understand, and aren’t usable from web workers when the prototype is lost and other cases when we don’t know if we have a Cartesian3, for example. I also haven’t found them to make code any cleaner. I’d rather all the consuming code be consistent and there be less code for these fundamental types. Err, I’d have to see it in the profiler, but the prototype functions could be a tad slower since they generally delegate to the non-prototype functions.

I don’t necessarily want to do this right away (but soon and swift is best), but would just like to submit an issue.

Thoughts?

Patrick

I 100% agree with you, but my one concern would be usability for new users. If we don’t think that’s a problem, then I would encourage making this change sooner rather than later.

A related change I would propose would be to require a result parameters for object return types, rather than making it optional. This would go a long way to helping with memory pressure issues on garbage collection. This has less to do with code maintenance and more to do with performance. Even trying to follow this rule is hard in our own code because it’s easy to accidentally use the non-result versions.

I submitted #1082 for the prototype functions.

As for requiring the result parameter for object return types, I am also for it. Given that it gives the user less choices, it makes the API easier to use in some sense, and certainty makes it easier to write fast code by default.

Patrick