Best term for describing the relationship between member and container in JavaScript

In JavaScript you could consider the relationship between two objects to be like a "container" and a "member". For example:

var c1 = {m:1};

function C() {this.m = 1;} var c2 = new C();

function C() {var m = 1;} var c3 = new C();

In each of these cases there is a relationship between the c object and the m object. You could say that in first case that m is a static member of c1. In the second case m is an instance member of c2. And in the third case m is an inner member of c3.

I suspect these terms are not technically correct in the case of the JavaScript Language, but in my experience, they are in common usage and are understood by most JavaScript developers. So my question is: what single word would you use to describe all these relationships? For example, would you say the "attachment" of m to c is "static"; or the "membership" of m to c is "instance"; etc.? The ????? of m to c is "inner"? If you see what I mean.

The use case is that I am documenting a JavaScript library and I've chosen to organise the documented objects into containers and then, under that, into members of that container. Then I'd like to organise the members b开发者_开发技巧ased on their "relationship" to their container: { inner, instance, or static }. Is there a word that describes that relationship?

---

I'd say, in the first case (this.m), m is a property of the object which is publicly accessible. Strictly speaking, all properties you can define are "public" because JavaScript does not have the concept of visibility.

In the second, m is just a variable local to the constructor function. What you name it depends on what you are doing with it. If you define other, public, functions (methods) in the constructor, then you could call m a "private property", as it is not accessible from the outside, but accessible by the methods. Although this is technically not correct, I think most people would understand what you mean. I would also mention explicitly (in a comment) that you use closures to simulate these "private properties" with local variables.

---

I prefer to read documentation that doesn't invent new terms. So I would prefer if they are referred to as properties and local variables. If you need to differentiate between properties that aren't supposed to change[1] and properties where changing them is a part of an API, I'd document them as just that, without inventing new words. For example, "m: Property. Do not change." and "x: Property. Changing this will foo bar."

A local variable is a local variable, that I don't see the point in documenting if these are API docs you're writing. It can't be changed, unless you provide a function to change it of course, Then you only need to document that function and not the internal local variable you use to back it.

[1] With emphasis on supposed, since technically speaking you can change it as much as you want.

---

Based on Felix Kling's answer I did some deeper research and have decided all I am dealing with here is properties of different things. To illustrate (and adding in a fourth case):

Given C.m = 1; function C() { this.m = 2; var m = 3; } C.prototype.m = 4;

• The value set to 1 is a property of the constructor function.
• The value set to 2 is a property of the instance.
• The value set to 3 is a local property (or a property of the constructor function's activation object?)
• The value set to 4 is a property of the constructor prototype.

Noting that the instance property (on this) will shadow the prototype property of the same name.