Linted code
CI: https://travis-ci.org/nodejs/nan/builds/138059729
The explicitness vs. implicitness of constructors seems a bit random. What's the pattern?
V8 has MaybeLocal do conversion. I was a bit befuddled regarding Persistents, but tried to stick to that of V8 3.19 or so, which was the last one with single argument constructors. Some of them were explicit, others were not.
On June 13, 2016 9:10:52 AM GMT+03:00, Ben Noordhuis [email protected] wrote:
The explicitness vs. implicitness of constructors seems a bit random. What's the pattern?
You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nodejs/nan/pull/581#issuecomment-225496516
Most things are explicit now and personally I think that's better, particularly with persistent handles, because there is less opportunity for accidental memory leaks. Possibly less of an issue with v4 and newer than it is with v0.10 and v0.12 because v8::Persistent is by default non-copyable.
MaybeLocal, like you point out, is the odd duck out for some reason.
There, turned out there were rather many wrong things which had been masked by implicit conversion. Now it should be sorted out.
I think I understand why the code is doing what it's doing but it's really skirting UB territory now, isn't it?
Skirting, but never crossing. Nothing is virtual and no child has added any data members. Additionally, the horrible things only occur for old versions, which will not change retroactively.
I changed the casts to static_cast and added some tests to help put your mind at ease.
LGTM
Thanks for looking through this.
I did find an edge case in that it is now not reasonably possible to actually copy a Global from another Global. It will require a static_cast from Global to PersistentBase, which is presumably unavoidable and can be lived with. However, due to the way things are set up, that does not work either, since Global inherits from v8::PersistentBase but not from Nan::PersistentBase.
The best solution ought to be the normalization process from #492, which would set up the correct inheritance hierarchy, remove some code duplication and make everything better in the long run. I will open a new PR with these commits plus the additional ones.