You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But this will result in buggy code because the real function arguments from the actual code are:
set: function(key, value, options) {
So in order to properly override set, one would need specify the true arguments, and juggle those arguments around to determine whether value is really a value, or whether value is actually options, and so forth. It might also be a good idea to mention that unset calls set.
The text was updated successfully, but these errors were encountered:
I think that the assumption is that if you're overwriting provided methods that you're more or less going to be in control of how you're going to use them, and therefore would know if you needed to account flexible arity situations.
FWIW, there's also an even easier way to preserve this if you're ultimately falling back to the original method: just use apply instead of call
I agree with @wookiehangover. Using apply instead is a much nicer way to ensure the original arguments get passed (just make sure you don't change them).
As for unset calling set, that's an implementation detail that can be garnered from reading the source and isn't really relevant to the documentation.
The documentation defines
Model.set
's function arguments like this:model.set(attributes, [options])
And down further states that one could override
set
like this:But this will result in buggy code because the real function arguments from the actual code are:
set: function(key, value, options) {
So in order to properly override
set
, one would need specify the true arguments, and juggle those arguments around to determine whethervalue
is really a value, or whethervalue
is actuallyoptions
, and so forth. It might also be a good idea to mention thatunset
callsset
.The text was updated successfully, but these errors were encountered: