JavaScript terminology: non-function-valued property

# Axel Rauschmayer (14 years ago)

I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are:

  • instance variable
  • member variable
  • field

OO literature sometimes uses the term “attribute” but that is already taken by ES-262.

# Brendan Eich (14 years ago)

On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote:

I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are:

Why do you need this term? In what practical sentence would you use it?

# Axel Rauschmayer (14 years ago)

To contrast non-method properties with methods:

  • To say that instances usually only have non-method properties.
  • To say that primitives can have non-method properties, but don’t have their own methods (they borrow them from their wrapper types).

Maybe “non-method property” is good enough for that purpose.

# Mike Shaver (14 years ago)

Which primitives have own properties? I thought even "str".length conceptually came from the prototype.

Mike On Jul 22, 2011 6:13 PM, "Axel Rauschmayer" <axel at rauschma.de> wrote:

To contrast non-method properties with methods:

  • To say that instances usually only have non-method properties.
  • To say that primitives can have non-method properties, but don’t have

their own methods (they borrow them from their wrapper types).

Maybe “non-method property” is good enough for that purpose.

On Jul 23, 2011, at 0:00 , Brendan Eich wrote:

On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote:

I’m still wondering if there is an established term for a

non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are:

Why do you need this term? In what practical sentence would you use it?

/be

  • instance variable
  • member variable
  • field

OO literature sometimes uses the term “attribute” but that is already

taken by ES-262.

# Axel Rauschmayer (14 years ago)

Possible. I assumed, because String.prototype.length does not seem to be generic (in the sense that, say, String.prototype.trim() is).

Object.getOwnPropertyDescriptor(String.prototype, "length") { value: 0, writable: false, enumerable: false, configurable: false }

In contrast, trim() is clearly borrowed from the wrapper’s prototype:

> "".trim === String.prototype.trim
true

ES-262, Sect. 8.4 only says: “The String type is the set of all finite ordered sequences of zero or more 16-bit unsigned integer values” (etc.). It does not mention how indexed access or length is handled.

# Jeff Walden (14 years ago)

On 07/22/2011 03:16 PM, Mike Shaver wrote:

Which primitives have own properties? I thought even "str".length conceptually came from the prototype.

Spec-wise, it comes from the boxed String object created when you attempt to look up a property on a primitive string. It's the same for "str"[0] and so on. (Serious implementations probably wouldn't actually box up the primitive in either case, of course, and would have fast-path logic.)

# Rick Waldron (14 years ago)

I'd like to speak on behalf of the JavaScript Community that you mentioned above... Unequivocally, a property is a property and method is a property whose value is a function.

Simply, "property" and "method". This terminology is used widely in publication and conversation.

# Axel Rauschmayer (14 years ago)

In strict-mode, "this" isn’t boxed in, say, String.prototype.* methods. But I don’t know how/whether that reflects the spec.

# Jeff Walden (14 years ago)

On 07/22/2011 04:13 PM, Axel Rauschmayer wrote:

In strict-mode, "this" isn’t boxed in, say, String.prototype.* methods. But I don’t know how/whether that reflects the spec.

This is not quite precisely true. See the second algorithm in 8.7 GetValue(V). If you implement exactly the steps in the spec, the boxing occurs whenever you look up a property on a primitive (step 1 of that algorithm) -- be that a data property whose value is a method, a data property whose value isn't a method, or an accessor property. It happens, however, that that boxed object itself is never directly exposed to code in the program being executed. So it's possible for an implementation to never actually box |this| in step 1, so long as it appears to behave as if it did.

Note that if you have an accessor property looked up this way, the |this| seen, if |this| is boxed because the accessor is a function whose code is non-strict, is not by the exact spec algorithm the same as the object created in step 1 in the spec. But again, because the object in step 1 is never exposed, an implementation might box up only one object for both uses. (Or none, even, if it can get away with such an optimization -- say, because the accessor function never evaluates |this|.)

# Allen Wirfs-Brock (14 years ago)

On Jul 22, 2011, at 4:28 PM, Jeff Walden wrote:

On 07/22/2011 04:13 PM, Axel Rauschmayer wrote:

In strict-mode, "this" isn’t boxed in, say, String.prototype.* methods. But I don’t know how/whether that reflects the spec.

This is not quite precisely true. See the second algorithm in 8.7 GetValue(V). If you implement exactly the steps in the spec, the boxing occurs whenever you look up a property on a primitive (step 1 of that algorithm) -- be that a data property whose value is a method, a data property whose value isn't a method, or an accessor property. It happens, however, that that boxed object itself is never directly exposed to code in the program being executed. So it's possible for an implementation to never actually box |this| in step 1, so long as it appears to behave as if it did.

Note that if you have an accessor property looked up this way, the |this| seen, if |this| is boxed because the accessor is a function whose code is non-strict, is not by the exact spec algorithm the same as the object created in step 1 in the spec. But again, because the object in step 1 is never exposed, an implementation might box up only one object for both uses. (Or none, even, if it can get away with such an optimization -- say, because the accessor function never evaluates |this|.)

There is a way to detect that a different object is used in the private value [[Ge]] algorithm of 8.7.1.

Do:

Object.defineProperty(Number.prototype, "checkSameThis", {configurable: true, get: function () { "use strict"; this.accessorThis = this; return function () {return this.hasOwnProperty("accessorThis ") && this.accessorThis ===this}; } }); alert(1.0.checkSameThis()); //should be false according to ES5 spec.

then try

alert(new Number(1.0).checkSameThis()); //should be true according to ES5 spec.

# Allen Wirfs-Brock (14 years ago)

On Jul 22, 2011, at 3:16 PM, Mike Shaver wrote:

Which primitives have own properties? I thought even "str".length conceptually came from the prototype.

No, 15.5.5/15.5.5.1 says that each string object (ie, each string wrapper) has its own "length" property.