If you need a different random function, you write a different random function either way. Having one function do nothing but call another function does nothing.

[–] loutr@sh.itjust.works 23 points 1 day ago (1 children)

There are several legit reasons why you'd do this. Unit tests, for example: override getRandom() with an implementation that always returns the same series of numbers, and now you have repeatable tests without touching the production code.

[–] WhiteRice@lemmy.ml 1 points 1 day ago* (last edited 1 day ago) (1 children)

Can you override Math.random within a local scope?

At my shop we do create generic covers for vendor specific functionality, for the reasons you stated. Though the practice was started in case we ever needed to swap vendors.

[–] bleistift2@sopuli.xyz 9 points 1 day ago

You can, but you shouldn’t. You don’t know what else relies on Math.random. That’s why there’s the wrapper function. That you can override in unit tests without worrying about other, unrelated code.

[–] x1gma@lemmy.world 4 points 1 day ago

It's not about a different function providing different randomness, but providing a compatible implementation for environments not supporting the "regular" implementation.

If this screenshot is legit, I guarantee you that either the library is older and there was some weird branching for IE or it's brand new and had branching for the hot new JS runtime / cross compiling.

Supporting a metric fuckton of browsers and environments takes the same amount of shims.