i mean its still good to use an abstraction layer in case you ever have to change the underlying call; it’s far easier to change it in one place instead of replacing every call
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.
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.
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.
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.
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.
i mean its still good to use an abstraction layer in case you ever have to change the underlying call; it’s far easier to change it in one place instead of replacing every call
Is this a joke?
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.
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.
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.
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.
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.
Just do a find and replace
YAGNI