Terminology: named data properties

Dean Landolt dean at deanlandolt.com
Tue Aug 7 05:04:02 PDT 2012

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...
> 1. Most devs don't even use the term "accessor", instead they say
> "getter-setters"
> 2. 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)
> 3. "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.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:value_objects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120807/ab3869f4/attachment.html>

More information about the es-discuss mailing list