But I would strongly advise against using prototypes. Make a static Vector3Utility class for yourself and use it like Vector3Utility.toFixed(new Vector3( 0, 0, 0 ));
instead
or just make that function and export it out of some file.
or extend the Vector3 class and make your own like
class MyVector3 extends Vector3 {
toFixed(digits: number) {
/** same stuff */
}
}
Could you please clarify why it’s better not to do that?
sure here’s a wikipedia article about it:
if you make whatever you’re writing a library, and someone else uses your library, they don’t know that you prototyped smth and might use the same prototype name
if you modify smth & you’re doing anything other than reading (and w/ javascript getters it’s very hard to know what’s actually pure reading) you might make a change that any other code that depends on Vector3 might not expect.
if you have multiple ppl working on a codebase, it just gets harder to document what’s from the source lib and what’s yours, which results in wasted time searching docs / forums looking for answers to things that the original lib doesn’t cover in the first place and just general confusion.
what if BJS rolls out an update tomorrow and has their own implementation of toFixed that is crucial to the functioning of Vector3? your code will break instantly on upgrade. So case in point it makes your code less modular and harder to switch out between different versions of the same library or between similar compatible libraries.
Seeing as all of this potential headache can be avoided by just not using prototypes and exporting / making it a separate function. it’s generally considered better in most cases to avoid using prototypes like the plague.
(I’m sure there can be niche cases where using prototypes is actually the correct choice, but they are few and far between and I myself have only ever encountered 1 such case)
Hm, that makes sense. Thanks a lot for such detailed explanation! That really makes harder migrating a code from one project to another, not to forget to move this hack too.