util: fix constructor/instanceof checks by mscdex · Pull Request #3385 · nodejs/node

mscdex · 2015-10-15T16:57:03Z

util: fix constructor/instanceof checks

These new checks are similar to the one introduced in 089d688, but for other types of objects. Specifically, if an object was created in a different context, the constructor object will not be the same as the constructor object in the current context, so we have to compare constructor names instead.

evanlucas · 2015-10-15T16:58:17Z

LGTM. is there anywhere else we are relying on similar functionality?

mscdex · 2015-10-15T17:01:59Z

Yeah, I guess I'll fix those up too while I'm in there.

lucthev · 2015-10-15T19:16:59Z

Should this be typeof obj !== 'undefined' or obj !== undefined, like above?

mscdex · 2015-10-15T19:18:43Z

Updated to fix the other constructor/instanceof checks.

CI: https://ci.nodejs.org/view/iojs/job/node-test-pull-request/515

evanlucas · 2015-10-15T19:21:40Z

Just curious, but I wonder if the isPromise, etc are faster than v8::Value::IsPromise. I would assume so, since they aren't doing the call into c++, but not sure

mscdex · 2015-10-15T19:25:43Z

Updated again to fix typo. CI: https://ci.nodejs.org/view/iojs/job/node-test-pull-request/516

vkurchatkin · 2015-10-15T19:42:16Z

This doesn't seem better than Object.prototype.toString

mscdex · 2015-10-15T19:56:01Z

@vkurchatkin That won't work for Promises though. I've now replaced isMap() and isSet().

targos · 2015-10-15T20:00:43Z

@mscdex I don't know if Map and Set can be subclassed, but I think your first version had the advantage to catch this:

classMyMapextendsMap{}util.inspect(newMyMap)

mscdex · 2015-10-15T20:09:28Z

@targos They can be and apparently Object.prototype.toString() works for subclasses too. There were already separate tests for those cases.

CI after replacing Map/Set check implementations: https://ci.nodejs.org/view/iojs/job/node-test-pull-request/517/

evanlucas · 2015-10-21T11:30:15Z

I'm still a little concerned about using objectToString. I thought that wasn't as reliable?

mscdex · 2015-10-21T15:36:13Z

@evanlucas Unreliable in what way? We're already using the same method in other util methods for checking for other types such as Date, RegExp, and Error.

evanlucas · 2015-10-21T15:48:04Z

maybe I'm thinking about once @@toStringTag lands in v8...I could have sworn I remember seeing that it was not reliable...nevermind though

evanlucas · 2015-10-21T15:50:13Z

LGTM if CI is happy

jasnell · 2015-10-21T17:12:05Z

As much as depending on objectToString bothers me, I'm not sure there's a better way. LGTM so long as CI is happy

mscdex · 2015-10-21T17:42:41Z

@jasnell Well, previously I was walking the prototype chain (similar to what I'm currently doing for checking for promises), but I'm not sure what the performance differences are.

jasnell · 2015-10-21T17:44:14Z

Yeah, like I said, I'm not sure there's a better way. It just makes me sad to be forced to rely on toString checks

jasnell · 2015-10-22T23:14:26Z

Kicked off another CI run, just to be sure since the last one came up red: https://ci.nodejs.org/job/node-test-pull-request/567/

jasnell · 2015-10-22T23:17:47Z

@mscdex .. hmm... thinking... would this qualify as a semver-minor or major? it likely shouldn't but want to be sure

mscdex · 2015-10-22T23:21:42Z

Wow, looks like there's something missing from a previous commit... an addon test is looking for a debug module...

mscdex · 2015-10-22T23:23:03Z

Personally I would see this as a bug fix, so I wouldn't see it as a semver-major. Not sure whether it'd be a semver-minor or not though.

jasnell · 2015-10-22T23:27:23Z

Very odd... testing a clean build locally on osx...

jasnell · 2015-10-22T23:31:56Z

@mscdex ... not seeing the same failure locally on osx ... can you test on your end?

trevnorris · 2015-10-23T19:08:46Z

FWIW calling into native is cheap, the call itself is simple enough:

voidCheckIsPromise(const FunctionCallbackInfo<Value>& args) {
args.GetReturnValue().Set(args[0]->IsPromise());
}

And this method is more definitive.

jasnell · 2015-11-05T18:51:38Z

New CI: https://ci.nodejs.org/job/node-test-pull-request/676/

@mscdex ... did you see the last comment from @trevnorris ?

mscdex · 2015-11-05T20:23:33Z

@jasnell I've removed the js isPromise() and am just calling inspectPromise() every time which already does a C++-based promise check like @trevnorris suggested.

targos · 2015-11-05T20:27:53Z

this comment isn't relevant anymore

What do you mean? A mirror is still only created if it's been determined the object is a promise. Do you mean the "superficially" part?

Yes, now the check isn't superficial. Also the comment isn't in the right context. It is not obvious here that we create an object mirror.
I know the change was made earlier but do you mind moving it to the inspectPromise declaration ?

I personally think it's fine the way it is.

jasnell · 2015-11-05T22:55:11Z

LGTM. CI is red but the failures do not appear to be related.

These new checks are similar to the one introduced in 089d688, but for other types of objects. Specifically, if an object was created in a different context, the constructor object will not be the same as the constructor object in the current context, so we have to compare constructor names instead.

mscdex · 2015-12-01T01:58:32Z

@targos I've updated the comment about Promises. LGTY?

mscdex · 2015-12-01T02:00:16Z

I ran through CI one more time and only saw a few unrelated errors on Windows.

targos · 2015-12-01T02:02:14Z

LGTM

These new checks are similar to the one introduced in 089d688, but for other types of objects. Specifically, if an object was created in a different context, the constructor object will not be the same as the constructor object in the current context, so we have to compare constructor names instead. PR-URL: #3385 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>

mscdex · 2015-12-01T02:45:48Z

Landed in 82b8355.

These new checks are similar to the one introduced in 089d688, but for other types of objects. Specifically, if an object was created in a different context, the constructor object will not be the same as the constructor object in the current context, so we have to compare constructor names instead. PR-URL: #3385 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>

These new checks are similar to the one introduced in 089d688, but for other types of objects. Specifically, if an object was created in a different context, the constructor object will not be the same as the constructor object in the current context, so we have to compare constructor names instead. PR-URL: nodejs#3385 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>

mscdex added the util Issues and PRs related to the built-in util module. label Oct 15, 2015

mscdex force-pushed the fix-object-constructor-check branch from 332647b to 68e2f1eCompare October 15, 2015 18:55

mscdex changed the title ~~util: fix check for Object constructor~~util: fix constructor/instanceof checksOct 15, 2015

lucthev reviewed Oct 15, 2015
View reviewed changes

Comment threadlib/util.js Outdated
lucthevOct 15, 2015
Copy link
Copy Markdown
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be typeof obj !== 'undefined' or obj !== undefined, like above?

mscdex force-pushed the fix-object-constructor-check branch from 68e2f1e to 0450980Compare October 15, 2015 19:20

mscdex force-pushed the fix-object-constructor-check branch from 0450980 to f8cb886Compare October 15, 2015 19:55

mscdex force-pushed the fix-object-constructor-check branch from f8cb886 to cdd15fbCompare November 5, 2015 20:21

targos reviewed Nov 5, 2015
View reviewed changes

mscdex mentioned this pull request Dec 1, 2015
util.inspect different in vm #4080
Closed

mscdex force-pushed the fix-object-constructor-check branch from cdd15fb to 7b775daCompare December 1, 2015 01:57

mscdex closed this Dec 1, 2015

This was referenced Dec 8, 2015
Release proposal: v5.2.0 #4180
Closed
Release proposal: v5.2.0 (Stable) #4181
Merged

rvagg mentioned this pull request Dec 17, 2015
Release 4.2.4 Planning #4321
Closed

mscdex deleted the fix-object-constructor-check branch December 17, 2015 17:59

jasnell added the lts-watch-v4.x label Dec 17, 2015

MylesBorins added land-on-v4.x and removed lts-watch-v4.x labels Dec 29, 2015

MylesBorins mentioned this pull request Jan 19, 2016
V4.2.5 proposal #4768
Merged

Uh oh!

Uh oh!

Conversation

mscdex commented Oct 15, 2015

Uh oh!

evanlucas commented Oct 15, 2015

Uh oh!

mscdex commented Oct 15, 2015

Uh oh!

lucthevOct 15, 2015

Choose a reason for hiding this comment

Uh oh!

mscdex commented Oct 15, 2015

Uh oh!

evanlucas commented Oct 15, 2015

Uh oh!

mscdex commented Oct 15, 2015

Uh oh!

vkurchatkin commented Oct 15, 2015

Uh oh!

mscdex commented Oct 15, 2015

Uh oh!

targos commented Oct 15, 2015

Uh oh!

mscdex commented Oct 15, 2015

Uh oh!

evanlucas commented Oct 21, 2015

Uh oh!

mscdex commented Oct 21, 2015

Uh oh!

evanlucas commented Oct 21, 2015

Uh oh!

evanlucas commented Oct 21, 2015

Uh oh!

jasnell commented Oct 21, 2015

Uh oh!

mscdex commented Oct 21, 2015

Uh oh!

jasnell commented Oct 21, 2015

Uh oh!

jasnell commented Oct 22, 2015

Uh oh!

jasnell commented Oct 22, 2015

Uh oh!

mscdex commented Oct 22, 2015

Uh oh!

mscdex commented Oct 22, 2015

Uh oh!

jasnell commented Oct 22, 2015

Uh oh!

jasnell commented Oct 22, 2015

Uh oh!

trevnorris commented Oct 23, 2015

Uh oh!

jasnell commented Nov 5, 2015

Uh oh!

mscdex commented Nov 5, 2015

Uh oh!

targosNov 5, 2015

Choose a reason for hiding this comment

Uh oh!

mscdexNov 5, 2015

Choose a reason for hiding this comment

Uh oh!

targosNov 5, 2015

Choose a reason for hiding this comment

Uh oh!

jasnellNov 5, 2015

Choose a reason for hiding this comment

Uh oh!

jasnell commented Nov 5, 2015

Uh oh!

mscdex commented Dec 1, 2015

Uh oh!

mscdex commented Dec 1, 2015

Uh oh!

targos commented Dec 1, 2015

Uh oh!

mscdex commented Dec 1, 2015

Uh oh!