Modifying Number prototype

[chrisveness]

Modifying Number prototype

[chrisveness]

Extending Object, Array, or Function prototypes is absolutely a bad idea, even more so when done with quite general-purpose method names (Prototype ended up causing havoc with Function.prototype.bind()).

Not only can different libraries’ extensions define different semantics for the same method, but such extensions can have knock-on effects (resulting for instance in the need for hasOwnProperty() workarounds).

Extending DOM objects is similarly ill advised (again, Prototype’s getElementsByClassName() is a classic example).

However, extending primitive objects with methods with obvious semantics is not the same. String.trim() was widely implemented, without issues, before finally being adopted into the language.

I don’t think toRadians() and toDegrees() are sufficiently ubiquitous ever to make it into the language, but they have obvious unambiguous semantics, and I cannot see risks in having them as Number methods.

If you can highlight specific risks, I will reconsider, but otherwise I find toRadians() and toDegrees() usefully idiomatic.

[chrisveness]

(Oh, and pad() will be replaced as soon as padStart() is supported by Chrome & Edge).

[jamiewinder]

I don't necessarily disagree. You're right that the usual arguments against prototype changes aren't valid (e.g. clashes with another implementation).

Conversely though, I'm not sure what they add in terms of expressiveness. A number is a number, not an angle. I wouldn't put a toMiles on there for example.

I think the best argument I have is that it makes what would be a contained library into something which leaks into the global context, albeit subtly and largely unobtrusively.

Your call though of course.

Great library by the way, it's a big help.

[chrisveness]

Indeed, at the end of the day it’s a judgement call, one which has occupied me a fair bit.

In a library with numbers regularly representing angles, they are either degrees or radians, nothing else (ignoring gradians, of course). Hence it’s more analogous to String.toUpper() / String.toLower() than to Number.toMiles() (from what?).

Equally, the difference in expressiveness is not great. I prefer the ‘to’ conversion method to the function call, but it’s perhaps subjective and personal.

So the question is maybe whether users of the library would be inconvenienced by the leakage into the global context. I hope not, though if so, that might change my view.

Anyway, glad you appreciate the library!

[mightyiam]

It's a 🙅‍♂️...

😆

But really.