-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deepEqual fails to work with descendants of something with a null prototype #851
Comments
stefanpenner
added a commit
to stefanpenner/data
that referenced
this issue
Aug 13, 2015
Anyone have thoughts on this? Would love to act on feedback. |
I suspect, we can walk the chain and detect a deeper inheritance of null |
I'm take the holiday tomorrow to work on this, I want to see if I also bring a test to avoid any regressions. |
note, i took a quick stab at something: stefanpenner/data@6a53d42 it may or may not be of help. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the following works as expected.
Unfortunately, in practice
Object.create(null)
is fairly costly. To mitigate this cost a specializedNullObject
can be used. This Object has similar safe characteristics, but with dramatically reduced allocation costs.Reference implementation:
This leads us to the problem:
This fails because,
a.constructor !== b.constructor
anda.prototype !== null
relevant code in QUnit:
As QUnit already special cases
null
prototyped object with projo deepEquality, could we explore another special case to handle this scenario? Is there an alternative I am missing?One solution,
would be to also detect a
null
constructor.change to the NullObject constructor would be as follows:
Change to QUnit would require also checking for a null constructor.
note: this protocol does appear funky, but would be quite handy in practice
The text was updated successfully, but these errors were encountered: