Terminology: named data properties
On Monday, August 6, 2012 at 4:02 PM, Axel Rauschmayer wrote:
On es-discuss, I’ve seen the term “data properties” used for named data properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named value properties?
"value" usually means scalar, whereas "data" is accurately vague.
On es-discuss, I’ve seen the term “data properties” used for named data properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named value properties?
"value" usually means scalar, whereas "data" is accurately vague.
My understanding:
- Method: a property whose value is a function.
- Data property: a property that is not a method or an accessor (getter, setter). Example: “ES.next classes don’t let you directly create data properties in prototypes”.
- Value: the union of primitive values and objects.
On Monday, August 6, 2012 at 4:51 PM, Axel Rauschmayer wrote:
On es-discuss, I’ve seen the term “data properties” used for named data properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named value properties?
"value" usually means scalar, whereas "data" is accurately vague.
My understanding:
- Method: a property whose value is a function.
- Data property: a property that is not a method or an accessor (getter, setter). Example: “ES.next classes don’t let you directly create data properties in prototypes”.
- Value: the union of primitive values and objects.
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
-
Most devs don't even use the term "accessor", instead they say "getter-setters"
-
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
-
"method" is the only commonly used term
Rick Waldron wrote:
On Monday, August 6, 2012 at 4:51 PM, Axel Rauschmayer wrote:
On es-discuss, I’ve seen the term “data properties” used for named data properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named value properties?
"value" usually means scalar, whereas "data" is accurately vague.
My understanding:
- Method: a property whose value is a function.
- Data property: a property that is not a method or an accessor (getter, setter). Example: “ES.next classes don’t let you directly create data properties in prototypes”.
- Value: the union of primitive values and objects.
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
Most devs don't even use the term "accessor", instead they say "getter-setters"
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
"method" is the only commonly used term
Good points.
Axel, I don't think "we" can redefine the jargon commonly used by JS developers. It's enough to track and influence what's commonly written and spoken.
In the spec, even ignoring common usage, I would not try to mess with "data property" right now. As Rick notes, "value" may be taken to mean "primitive, not reference (object)."
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
Most devs don't even use the term "accessor", instead they say "getter-setters"
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
"method" is the only commonly used term
Good points.
Axel, I don't think "we" can redefine the jargon commonly used by JS developers. It's enough to track and influence what's commonly written and spoken.
In the spec, even ignoring common usage, I would not try to mess with "data property" right now. As Rick notes, "value" may be taken to mean "primitive, not reference (object)."
Got it. Wanted to avoid NIH in my writings, but will try my best to keep my own terminology consistent.
I thought value objects came from “compare by value”, but then I am still making Rick’s point.
On Mon, Aug 6, 2012 at 5:38 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
Most devs don't even use the term "accessor", instead they say "getter-setters"
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
"method" is the only commonly used term
Good points.
Axel, I don't think "we" can redefine the jargon commonly used by JS developers. It's enough to track and influence what's commonly written and spoken.
In the spec, even ignoring common usage, I would not try to mess with "data property" right now. As Rick notes, "value" may be taken to mean "primitive, not reference (object)."
Got it. Wanted to avoid NIH in my writings, but will try my best to keep my own terminology consistent.
I thought value objects came from “compare by value”, but then I am still making Rick’s point.
I'm fairly sure the term value typically has nothing to do with being * scalar* (strictly speaking a string isn't scalar) or even primitive. It simply means immutable and identified by content, not reference -- and can just as easily apply to product types. This is also the definition given by the value object strawman [1] -- which I really hope to see advanced at some point.
On Tue, Aug 7, 2012 at 8:04 AM, Dean Landolt <dean at deanlandolt.com> wrote:
On Mon, Aug 6, 2012 at 5:38 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
Most devs don't even use the term "accessor", instead they say "getter-setters"
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
"method" is the only commonly used term
Good points.
Axel, I don't think "we" can redefine the jargon commonly used by JS developers. It's enough to track and influence what's commonly written and spoken.
In the spec, even ignoring common usage, I would not try to mess with "data property" right now. As Rick notes, "value" may be taken to mean "primitive, not reference (object)."
Got it. Wanted to avoid NIH in my writings, but will try my best to keep my own terminology consistent.
I thought value objects came from “compare by value”, but then I am still making Rick’s point.
I'm fairly sure the term value typically has nothing to do with being * scalar* (strictly speaking a string isn't scalar) or even primitive. It simply means immutable and identified by content, not reference -- and can just as easily apply to product types. This is also the definition given by the value object strawman [1] -- which I really hope to see advanced at some point.
This is my understanding of values as well.
On Tuesday, August 7, 2012 at 8:36 AM, Russell Leggett wrote:
On Tue, Aug 7, 2012 at 8:04 AM, Dean Landolt <dean at deanlandolt.com (mailto:dean at deanlandolt.com)> wrote:
On Mon, Aug 6, 2012 at 5:38 PM, Axel Rauschmayer <axel at rauschma.de (mailto:axel at rauschma.de)> wrote:
What is the endgame? Add more terminology to the spec or try to define a term to be adopted into the spoken lexicon?
The former doesn't currently have any ambiguity and the latter is tough because...
Most devs don't even use the term "accessor", instead they say "getter-setters"
Most devs will use "value" to describe a scalar and "object" or "reference" to describe an object... "data" is used to mean either/both (which is why Brendan's "value objects" makes complete sense: looks like a value, but is actually an object)
"method" is the only commonly used term
Good points.
Axel, I don't think "we" can redefine the jargon commonly used by JS developers. It's enough to track and influence what's commonly written and spoken.
In the spec, even ignoring common usage, I would not try to mess with "data property" right now. As Rick notes, "value" may be taken to mean "primitive, not reference (object)."
Got it. Wanted to avoid NIH in my writings, but will try my best to keep my own terminology consistent.
I thought value objects came from “compare by value”, but then I am still making Rick’s point.
I'm fairly sure the term value typically has nothing to do with being scalar (strictly speaking a string isn't scalar) or even primitive. It simply means immutable and identified by content, not reference -- and can just as easily apply to product types. This is also the definition given by the value object strawman [1] -- which I really hope to see advanced at some point.
This is my understanding of values as well.
I agree, but I'm not interested in arguing the meaning of "value". I was simply trying to illustrate what the average web developer will think first.
On es-discuss, I’ve seen the term “data properties” used for named data properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named value properties?