Proxies and function names: properties that are always non-configurable

# Brandon Benvie (13 years ago)

With Direct Proxies there's no such thing as a fully virtual object. Virtualized objects can be achieved by just creating a new empty/placeholder object with the desired invariants ([[prototype]], [[class]], etc). This is all well and good except it turns a handful of non-internal properties into invariants as well, mostly the properties auto-installed on functions. [arguments, name, caller, length] are non-configurable non-writable, prototype is non-configurable.

With other objects you can mostly manage the problem by creating a new instance using Object.create since nothing comes preinstalled. This obviously doesn't work for a functions, nor have I seen semantics on how inheritance for functions is support to work once we actually have the ability to do that. Has this been discussed anywhere yet? Have the semantics of how inheritance for functions is supposed to work in to the above properties?

# David Bruant (13 years ago)

Le 13/04/2012 01:36, Brandon Benvie a écrit :

With Direct Proxies there's no such thing as a fully virtual object. Virtualized objects can be achieved by just creating a new empty/placeholder object with the desired invariants ([[prototype]], [[class]], etc). This is all well and good except it turns a handful of non-internal properties into invariants as well, mostly the properties auto-installed on functions. [arguments, name, caller, length] are non-configurable non-writable, prototype is non-configurable.

I think that fully virtualized objects is not a goal. Conservation of invariant is an important property specifically for what you're asking below. If it can be reassuring, I think fat arrow functions (or whatever simpler function is created) will not have the properties you mentionned, so it'll be possible to wrap them in proxies and have the properties you wish for.

With other objects you can mostly manage the problem by creating a new instance using Object.create since nothing comes preinstalled. This obviously doesn't work for a functions, nor have I seen semantics on how inheritance for functions is support to work once we actually have the ability to do that. Has this been discussed anywhere yet? Have the semantics of how inheritance for functions is supposed to work in to the above properties?

Since proxies preserve function invariants, what happens with proxies is what should happen with the wrapped function.

# Tom Van Cutsem (13 years ago)

2012/4/13 Brandon Benvie <brandon at brandonbenvie.com>

With other objects you can mostly manage the problem by creating a new instance using Object.create since nothing comes preinstalled. This obviously doesn't work for a functions, nor have I seen semantics on how inheritance for functions is support to work once we actually have the ability to do that. Has this been discussed anywhere yet? Have the semantics of how inheritance for functions is supposed to work in to the above properties?

There was a strawman proposal to add Function.create, inspired by Object.create (not sure what the latest status of that is): strawman:name_property_of_functions

Inheritance among functions is also enabled by Allen's proto operator: harmony:proto_operator

Not sure what is unclear about the semantics, though: AFAICT, both just entail creating regular Function instances whose [[prototype]] is not Function.prototype. This doesn't create any new interactions as far as proxies are concerned.