Stuff V8 will be breaking soon

Skimmed through v8.h@4.8.168, these will be deprecated soon:

ForceSet -> DefineOwnProperty (prefer CreateDataProperty)
Function::New -> return MaybeLocal
Object::SetAccessor -> return Maybe

I don't think it's worth breaking compatibility with a new major for this drivel yet. I'd like to keep NAN 2 working for at least a year (given no major overhauls of V8), so I propose aliasing Nan::ForceSet to v8::DefineOwnProperty, ignoring v8::CreateDataProperty, and un-maybefying v8::Function::New and v8::Object::SetAccessor.

and un-maybefying v8::Function::New and v8::Object::SetAccessor.

will be a breaking change no?

No, the idea is to keep them working the current way, without maybes.

However, what is the actual Node release policy now after 5 has been released? My understanding is that it will be around for half a year or so, but won't be an LTS release, which 4 is. Will there be a 6, 7, 8, and 9 (given V8's six week cycle) in those six months, or are future major versions (and thereby V8 upgrades) off the table until six months have passed?

If Node 6 won't be out for six months, the best option is probably to wait for more breaking V8 changes to accumulate in the meantime and then to break the API if more changes have accumulated, or to keep compatibility if these are the only offenders or they can be reasonably covered with only additive changes.

As mentioned elsewhere, there will be a major overhaul the day we can finally stop supporting 0.8 and 0.10, either voluntarily, or because it simply is not feasible to keep it working any longer.

@kkoopa

@kkoopa the Node.js LTS release schedule at the bottom of this page should provide some of the information you're looking for.

Alright, if that schedule will be held, it seems like we could even drop 0.8, 0.10, 0.12 and all of io.js in a year from now, moving on to the regular schedule of supporting two LTSs after that. However, it is still hard to determine such things in advance. It should at least not be necessary to do a new major of NAN until April next year.

so I propose aliasing Nan::ForceSet to v8::DefineOwnProperty

From includes.v8.h:

  // Defines a configurable, writable, enumerable property with the given value
  // on the object unless the property already exists and is not configurable
  // or the object is not extensible.

Which leads me to believe that CreateDataProperty/DefineOwnProperty will not forcefully override the propety, unlike ForceSet.

Ish... Need to take a closer look at it. The deprecation notice said to use one of those.

On November 3, 2015 1:49:08 AM GMT+02:00, Trevor Norris notifications@github.com wrote:

so I propose aliasing Nan::ForceSet to v8::DefineOwnProperty

From includes.v8.h:
// Defines a configurable, writable, enumerable property with the given
value
// on the object unless the property already exists and is not
configurable
 // or the object is not extensible.
Which leads me to believe that CreateDataProperty/DefineOwnProperty
will not forcefully override the propety, unlike ForceSet.

Reply to this email directly or view it on GitHub:
#504 (comment)

@trevnorris

@trevnorris The way I interpret that sentence is:
if (property.Exists() && (!property.Configurable() || !object.Extensible()))
v8::ForceSet is now a soon to be deprecated wrapper around v8::DefineObjectProperty.

Although DefineObjectProperty does not seem to be an exported function. I guess the only way to make sure is to write regression / unit tests.

Wrote quick script to check, and it appears to not forcefully override a property. Here's the C++:

void Run(const FunctionCallbackInfo<Value>& args) {
  Isolate* isolate = args.GetIsolate();
  Local<Context> ctx = isolate->GetCurrentContext();
  Local<Object> obj = args[0].As<Object>();
  Local<String> key = String::NewFromUtf8(isolate, "foo");
  Local<Number> num = Number::New(isolate, 42);

  //obj->CreateDataProperty(ctx, key, num).FromJust();
  obj->DefineOwnProperty(ctx, key, num).FromJust();
  //obj->ForceSet(key, num);
}

and the JS:

const obj = {};

Object.defineProperty(obj, 'foo', {
  value: 'bar',
  writable: false,
  enumerable: true,
});

console.log(obj);

run(obj);

console.log(obj);

Hmm, maybe we should check what's what with the V8 team. The sooner the better, as they are more likely to take requests into account on the current development branch. Is the intention not to have any way of forcing a property override? Is this something people need?

On November 3, 2015 8:27:54 PM GMT+02:00, Trevor Norris notifications@github.com wrote:

Wrote quick script to check, and it appears to not forcefully override
a property. Here's the C++:

void Run(const FunctionCallbackInfo<Value>& args) {
 Isolate* isolate = args.GetIsolate();
 Local<Context> ctx = isolate->GetCurrentContext();
 Local<Object> obj = args[0].As<Object>();
 Local<String> key = String::NewFromUtf8(isolate, "foo");
 Local<Number> num = Number::New(isolate, 42);

 //obj->CreateDataProperty(ctx, key, num).FromJust();
 obj->DefineOwnProperty(ctx, key, num).FromJust();
 //obj->ForceSet(key, num);
}

and the JS:

const obj = {};

Object.defineProperty(obj, 'foo', {
 value: 'bar',
 writable: false,
 enumerable: true,
});

console.log(obj);

run(obj);

console.log(obj);

Reply to this email directly or view it on GitHub:
#504 (comment)

@kkoopa

@kkoopa Has been confirmed that this will not be backwards compatible: https://code.google.com/p/v8/issues/detail?id=3485#c8

@kkoopa

Alright, guess that's the way it has to be then. New proposal: Backport one or both of those APIs on top of Set and ForceSet, making sure that things cannot be wrongly overridden.

On November 4, 2015 7:47:27 PM GMT+02:00, Trevor Norris notifications@github.com wrote:

@kkoopa Has been confirmed that this will not be backwards compatible:
https://code.google.com/p/v8/issues/detail?id=3485#c8

Reply to this email directly or view it on GitHub:
#504 (comment)

And the problem with that suggestion is that I can't find a way of checking if a v8::Object is extendable.

Any solutions or workarounds in sight for this? I'm getting deprecated messages when using ForceSet.

And now for a round of "no member named" for all the now-obsolete interfaces, thanks to distributions that jumped on v10 the instant it was released. I'm looking at you, Arch.

@kode54

@kode54 We also provides lts version of nodejs, but I think it’s good some people update it asap so that all bugs get fixed by the time it lands in other distros.

Do you think we can close this issue now 2.10 fixes (AFAIK) the problem? For packages failing, you just need to force the use of at least nan 2.10 to make it work. A bit like I did with Mattermost on Arch Linux.

Navigation Menu

Repository navigation

Stuff V8 will be breaking soon #504

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Stuff V8 will be breaking soon #504

Description

Activity

rvagg commented on Oct 28, 2015

kkoopa commented on Oct 28, 2015

kkoopa commented on Oct 29, 2015

fivdi commented on Nov 1, 2015

kkoopa commented on Nov 1, 2015

trevnorris commented on Nov 2, 2015

kkoopa commented on Nov 3, 2015

kkoopa commented on Nov 3, 2015

kkoopa commented on Nov 3, 2015

trevnorris commented on Nov 3, 2015

kkoopa commented on Nov 3, 2015

trevnorris commented on Nov 4, 2015

kkoopa commented on Nov 4, 2015

kkoopa commented on Nov 9, 2015

paixaop commented on Oct 19, 2016

kode54 commented on Apr 30, 2018

ArchangeGabriel commented on May 3, 2018

wget commented on May 14, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions