Disguise accessor properties as data properties

[zherczeg]

This is a non-standard feature, and we can discuss how it should work. The only important thing is that it should have a negligible effect on performance.

[lygstate]

What's this for? any design notes?

[zherczeg]

This is a non-standard feature inspired by v8 engine. This allows disguising an accessor as data property. I.e. a message object created from a network packet can have a sender data property, but the property value is actually computed when the property is read. If this never happens, the property is never computed. Furthermore these accessor functions cannot be queried from the JS code, so it cannot be misused by the application.

Since this feature is non-standard, we can make our decisions about it. The most important thing for me: the performance impact should be minimal.

These properties can be created by setting a flag in the C API. This flag is also set, when the property descriptor is read, so the API functions can get these accessors. If an application never creates such properties, it can ignore this flag, which is useful for backward compatibility.
Option: the C API could also return with the data property.

Form JS side, Object.getOwnPropertyDescriptor and Object.getOwnPropertyDescriptors returns these as data properties. If the property has a setter, writable property is set to true, otherwise it is false.
Danger: these functions can change the object state, which does not normally happen.
Option: writable could be determined in another way, but I think this is good in practice.

Property definition:

Configurable properties: currently reconfiguring these accessors can be done.
Option: when the property configured as data, the setter function could be called. Question: what should happen if the setter is missing.

Non-configurable properties: when the property is defined as data property, the setter is called. If the setter is not present, it is compared to the returned value of the getter. Even in non-configurable case, writable can be changed from true to false. Currently the setter is released in this case.
Option: changing writable could yield an error.

[lygstate]

This is a non-standard feature inspired by v8 engine. This allows disguising an accessor as data property. I.e. a message object

An reference link to v8 are appreciated, also what's the advantage of this, any demo of it?

created from a network packet can have a sender data property, but the property value is actually computed when the property is read. If this never happens, the property is never computed. Furthermore these accessor functions cannot be queried from the JS code, so it cannot be misused by the application.

Since this feature is non-standard, we can make our decisions about it. The most important thing for me: the performance impact should be minimal.

These properties can be created by setting a flag in the C API. This flag is also set, when the property descriptor is read, so the API functions can get these accessors. If an application never creates such properties, it can ignore this flag, which is useful for backward compatibility.
Option: the C API could also return with the data property.

Form JS side, Object.getOwnPropertyDescriptor and Object.getOwnPropertyDescriptors returns these as data properties. If the property has a setter, writable property is set to true, otherwise it is false.
Danger: these functions can change the object state, which does not normally happen.
Option: writable could be determined in another way, but I think this is good in practice.

Property definition:

Configurable properties: currently reconfiguring these accessors can be done.
Option: when the property configured as data, the setter function could be called. Question: what should happen if the setter is missing.

Non-configurable properties: when the property is defined as data property, the setter is called. If the setter is not present, it is compared to the returned value of the getter. Even in non-configurable case, writable can be changed from true to false. Currently the setter is released in this case.
Option: changing writable could yield an error.

[zherczeg]

Needed to implement this https://v8.dev/docs/stack-trace-api

[zherczeg]

Depends on #4373

[galpeter]

This is an API breaking change and should be documented.