How to declare my own prototype in Typescript for Vector3?

Questions
1

I wanna create a function that beutifies Vector3 output.

Can you please help me? I tried to start with it. It’s not working code, but that’s the main idea what I try to make :smile:

That’s for ES6 packages.

declare global
{
	interface Vector3
	{
		toFixed( digits: number ): string;
	}
}

Vector3.prototype.toFixed = function ( digits: number ): string
{
	return `${ this.x.toFixed( digits ) }, ${ this.y.toFixed( digits ) }, ${ this.z.toFixed( digits ) }`;
}

// Using:
console.log( new Vector3( 0, 0, 0 ).to_fixed( 3 ) );
3

seems to work,

for ts you have to add the following to your global.d.ts

import "@babylonjs/core";

declare module "@babylonjs/core" {
	interface Vector3 {
		toFixed: ( digits: number ) => string;
	}
}

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 :open_mouth:
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 */
    }
}
4 Likes
4

Could you please clarify why it’s better not to do that?

1 Like
5

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)

1 Like
6

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.

1 Like
7

makes harder migrating a code from one project to another, not to forget to move this hack too

that too : P

1 Like