Closed thomasmichaelwallace closed 6 years ago
Hi, Basically, Sugar isn't designed to override native methods when they already exist. This functionality does exist, but is intended to polyfill methods when they do not exist or their implementations are not correct, so the syntax is a bit more complicated:
Sugar.Number.defineInstancePolyfill({
toString: function () { return 'hello'; }
}, true);
The last true
flag tells Sugar to always override existing methods (in this case toString
already exists) and is intended to allow it to override if the native implementation is incorrect.
Note that any of the ...Polyfill
methods will always extend only the browser native, so if you want to set this special behavior for Sugar chainables or static methods as well you'll have to define them separately (as you did above).
Also note that overriding native methods not as a polyfill is not advisable, so I would question the need to override it here, however to answer your question, there it is.
Cheers @andrewplummer
I'm not that stoked about overriding natives, to be honest, it's more of a thought experiment. We have a situation where we need to format our numbers in a specific way everywhere; which is easy to forget to do. So one of the ideas being passed around was to override native- which I didn't actually think was possible until I saw this library!
Hi,
I was trying out this library in the REPL in the documentation. I have a need to override the toString() property on the Number type, and thought Sugar might be able to do it.
As far as I can tell, this should make all numbers return "Hello" on
(1).toString()
. But instead it just returns the native implementation (1
).Am I doing something wrong, or is this a bug/limitation?
Thanks,