Are objects values?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Are objects values?

T.J. Crowder-2
I recently had an exchange which started out with my "correcting" someone who said "Functions are values" by saying "Function *references* are values. Functions are objects." He/she replied that objects are also values, and after much back and forth, cited [this part of the JavaScript spec][1]:

> An ECMAScript *language type* corresponds to values that are directly manipulated by an ECMAScript programmer using the ECMAScript language. The ECMAScript language types are Undefined, Null, Boolean, String, Symbol, Number, and Object. An *ECMAScript language value* is a value that is characterized by an ECMAScript language type.

...and said "So objects are values."

Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I asked a friend who, unlike me, did get comp sci theory at Uni, and he said "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it means just what I choose it to mean -- neither more nor less."

I've used the term "value" in explanations of variables, properties, and function arguments and in particular when explaining why `b = a` copies an object reference, not an object, from `a` to `b`. (Saying the *object reference* is the value.) It's been an invaluable aid to helping people "get" object references.

I'd be very sorry to hear that I was misusing a term of art. But I'd rather know. :-)

If I'm misusing "value," what should I use instead for that thing that actually gets stored in memory? How to explain the `b = a` thing with object references to beginners?

This is slightly off-topic for the thread, but also not, as I spend a lot of time explaining things to JavaScript beginners, and the authors of the text being used to tell me I'm wrong are on this list. :-)

Thanks,

-- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

kdex
Yes, objects/functions are values, but they are not *primitive* values.

The current draft uses the phrasing "object value" several times.

Section 4.3.3 explains that objects are "members of type Object", and a type
is, by definition, a set of values. Therefore, objects must be values.

On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:

> I recently had an exchange which started out with my "correcting" someone
> who said "Functions are values" by saying "Function *references* are
> values. Functions are objects." He/she replied that objects are also
> values, and after much back and forth, cited [this part of the JavaScript
>
> spec][1]:
> > An ECMAScript *language type* corresponds to values that are directly
>
> manipulated by an ECMAScript programmer using the ECMAScript language. The
> ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> Number, and Object. An *ECMAScript language value* is a value that is
> characterized by an ECMAScript language type.
>
> ...and said "So objects are values."
>
> Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I asked
> a friend who, unlike me, did get comp sci theory at Uni, and he said
> "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it
> means just what I choose it to mean -- neither more nor less."
>
> I've used the term "value" in explanations of variables, properties, and
> function arguments and in particular when explaining why `b = a` copies an
> object reference, not an object, from `a` to `b`. (Saying the *object
> reference* is the value.) It's been an invaluable aid to helping people
> "get" object references.
>
> I'd be very sorry to hear that I was misusing a term of art. But I'd rather
> know. :-)
>
> If I'm misusing "value," what should I use instead for that thing that
> actually gets stored in memory? How to explain the `b = a` thing with
> object references to beginners?
>
> This is slightly off-topic for the thread, but also not, as I spend a lot
> of time explaining things to JavaScript beginners, and the authors of the
> text being used to tell me I'm wrong are on this list. :-)
>
> Thanks,
>
> -- T.J. Crowder
>
> [1]:
> http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmascript-lan
> guage-types [2]: https://en.wikipedia.org/wiki/Value_(computer_science)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

Naveen Chawla

But references are also values. It's not a mutually exclusive thing


On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
Yes, objects/functions are values, but they are not *primitive* values.

The current draft uses the phrasing "object value" several times.

Section 4.3.3 explains that objects are "members of type Object", and a type
is, by definition, a set of values. Therefore, objects must be values.

On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> I recently had an exchange which started out with my "correcting" someone
> who said "Functions are values" by saying "Function *references* are
> values. Functions are objects." He/she replied that objects are also
> values, and after much back and forth, cited [this part of the JavaScript
>
> spec][1]:
> > An ECMAScript *language type* corresponds to values that are directly
>
> manipulated by an ECMAScript programmer using the ECMAScript language. The
> ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> Number, and Object. An *ECMAScript language value* is a value that is
> characterized by an ECMAScript language type.
>
> ...and said "So objects are values."
>
> Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I asked
> a friend who, unlike me, did get comp sci theory at Uni, and he said
> "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it
> means just what I choose it to mean -- neither more nor less."
>
> I've used the term "value" in explanations of variables, properties, and
> function arguments and in particular when explaining why `b = a` copies an
> object reference, not an object, from `a` to `b`. (Saying the *object
> reference* is the value.) It's been an invaluable aid to helping people
> "get" object references.
>
> I'd be very sorry to hear that I was misusing a term of art. But I'd rather
> know. :-)
>
> If I'm misusing "value," what should I use instead for that thing that
> actually gets stored in memory? How to explain the `b = a` thing with
> object references to beginners?
>
> This is slightly off-topic for the thread, but also not, as I spend a lot
> of time explaining things to JavaScript beginners, and the authors of the
> text being used to tell me I'm wrong are on this list. :-)
>
> Thanks,
>
> -- T.J. Crowder
>
> [1]:
> http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmascript-lan
> guage-types [2]: https://en.wikipedia.org/wiki/Value_(computer_science)_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

Sebastian Malton
Should not a value be able to be changed? I don't believe that you can change a function after definition; you can, however, change a function reference. 

Sent: August 19, 2017 7:44 PM
Subject: Re: Are objects values?

But references are also values. It's not a mutually exclusive thing


On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
Yes, objects/functions are values, but they are not *primitive* values.

The current draft uses the phrasing "object value" several times.

Section 4.3.3 explains that objects are "members of type Object", and a type
is, by definition, a set of values. Therefore, objects must be values.

On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> I recently had an exchange which started out with my "correcting" someone
> who said "Functions are values" by saying "Function *references* are
> values. Functions are objects." He/she replied that objects are also
> values, and after much back and forth, cited [this part of the JavaScript
>
> spec][1]:
> > An ECMAScript *language type* corresponds to values that are directly
>
> manipulated by an ECMAScript programmer using the ECMAScript language. The
> ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> Number, and Object. An *ECMAScript language value* is a value that is
> characterized by an ECMAScript language type.
>
> ...and said "So objects are values."
>
> Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I asked
> a friend who, unlike me, did get comp sci theory at Uni, and he said
> "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it
> means just what I choose it to mean -- neither more nor less."
>
> I've used the term "value" in explanations of variables, properties, and
> function arguments and in particular when explaining why `b = a` copies an
> object reference, not an object, from `a` to `b`. (Saying the *object
> reference* is the value.) It's been an invaluable aid to helping people
> "get" object references.
>
> I'd be very sorry to hear that I was misusing a term of art. But I'd rather
> know. :-)
>
> If I'm misusing "value," what should I use instead for that thing that
> actually gets stored in memory? How to explain the `b = a` thing with
> object references to beginners?
>
> This is slightly off-topic for the thread, but also not, as I spend a lot
> of time explaining things to JavaScript beginners, and the authors of the
> text being used to tell me I'm wrong are on this list. :-)
>
> Thanks,
>
> -- T.J. Crowder
>
> [1]:
> http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmascript-lan
> guage-types [2]: https://en.wikipedia.org/wiki/Value_(computer_science)_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

kdex
In reply to this post by Naveen Chawla
I never claimed it was. I'm sure the notion of "value" that ECMAScript wants
to convey is supposed to be something along the lines of "can be bound to an
identifier".

The semantics that are then defined over primitive/non-primitive values are a
completely different matter.

On Saturday, August 19, 2017 8:44:08 PM CEST Naveen Chawla wrote:

> But references are also values. It's not a mutually exclusive thing
>
> On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
> > Yes, objects/functions are values, but they are not *primitive* values.
> >
> > The current draft uses the phrasing "object value" several times.
> >
> > Section 4.3.3 explains that objects are "members of type Object", and a
> > type
> > is, by definition, a set of values. Therefore, objects must be values.
> >
> > On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> > > I recently had an exchange which started out with my "correcting"
> > > someone
> > > who said "Functions are values" by saying "Function *references* are
> > > values. Functions are objects." He/she replied that objects are also
> > > values, and after much back and forth, cited [this part of the
> > > JavaScript
> > >
> > > spec][1]:
> > > > An ECMAScript *language type* corresponds to values that are directly
> > >
> > > manipulated by an ECMAScript programmer using the ECMAScript language.
> >
> > The
> >
> > > ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> > > Number, and Object. An *ECMAScript language value* is a value that is
> > > characterized by an ECMAScript language type.
> > >
> > > ...and said "So objects are values."
> > >
> > > Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I
> >
> > asked
> >
> > > a friend who, unlike me, did get comp sci theory at Uni, and he said
> > > "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it
> > > means just what I choose it to mean -- neither more nor less."
> > >
> > > I've used the term "value" in explanations of variables, properties, and
> > > function arguments and in particular when explaining why `b = a` copies
> >
> > an
> >
> > > object reference, not an object, from `a` to `b`. (Saying the *object
> > > reference* is the value.) It's been an invaluable aid to helping people
> > > "get" object references.
> > >
> > > I'd be very sorry to hear that I was misusing a term of art. But I'd
> >
> > rather
> >
> > > know. :-)
> > >
> > > If I'm misusing "value," what should I use instead for that thing that
> > > actually gets stored in memory? How to explain the `b = a` thing with
> > > object references to beginners?
> > >
> > > This is slightly off-topic for the thread, but also not, as I spend a
> > > lot
> > > of time explaining things to JavaScript beginners, and the authors of
> > > the
> > > text being used to tell me I'm wrong are on this list. :-)
> > >
> > > Thanks,
> > >
> > > -- T.J. Crowder
> >
> > > [1]:
> > http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmascript-l
> > an>
> > > guage-types [2]: https://en.wikipedia.org/wiki/Value_(computer_science)
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Are objects values?

Alex Kodat-2
While it does appear the that ECMAScript spec calls objects values, that
seems pretty unintuitive to me. My intuition is that values are immutable
(functions can and frequently do have properties added to them). The typical
distinction seems to me between values and variables. If you set a variable
to an object value how is it that the variable value changes when you change
another variable? If, on the other hand, you view object values as
references to object then changing one variable's value will never change
another's which seems a nicer view of the world. But that was T.J.'s point,
I think.

Note that strings are also generally indistinguishable from immutable
objects and are generally passed by reference under the covers but, because
they're immutable, one can safely think of the value being the actual string
rather than the reference. Numbers can be and sometimes are implemented as
immutable objects too. Like V8 implements 32-bit signed integers as pure
values and larger numbers are boxed (into hidden objects) double values.

-----Original Message-----
From: es-discuss [mailto:[hidden email]] On Behalf Of kdex
Sent: Saturday, August 19, 2017 1:55 PM
To: [hidden email]
Subject: Re: Are objects values?

I never claimed it was. I'm sure the notion of "value" that ECMAScript wants
to convey is supposed to be something along the lines of "can be bound to an
identifier".

The semantics that are then defined over primitive/non-primitive values are
a completely different matter.

On Saturday, August 19, 2017 8:44:08 PM CEST Naveen Chawla wrote:

> But references are also values. It's not a mutually exclusive thing
>
> On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
> > Yes, objects/functions are values, but they are not *primitive* values.
> >
> > The current draft uses the phrasing "object value" several times.
> >
> > Section 4.3.3 explains that objects are "members of type Object",
> > and a type is, by definition, a set of values. Therefore, objects
> > must be values.
> >
> > On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> > > I recently had an exchange which started out with my "correcting"
> > > someone
> > > who said "Functions are values" by saying "Function *references*
> > > are values. Functions are objects." He/she replied that objects
> > > are also values, and after much back and forth, cited [this part
> > > of the JavaScript
> > >
> > > spec][1]:
> > > > An ECMAScript *language type* corresponds to values that are
> > > > directly
> > >
> > > manipulated by an ECMAScript programmer using the ECMAScript language.
> >
> > The
> >
> > > ECMAScript language types are Undefined, Null, Boolean, String,
> > > Symbol, Number, and Object. An *ECMAScript language value* is a
> > > value that is characterized by an ECMAScript language type.
> > >
> > > ...and said "So objects are values."
> > >
> > > Is he/she right? [Wikpedia][2] isn't much help, at least not to
> > > me. I
> >
> > asked
> >
> > > a friend who, unlike me, did get comp sci theory at Uni, and he
> > > said "...you're not wrong, but it's very Humpty Dumpty: When I use
> > > a word, it means just what I choose it to mean -- neither more nor
less."

> > >
> > > I've used the term "value" in explanations of variables,
> > > properties, and function arguments and in particular when
> > > explaining why `b = a` copies
> >
> > an
> >
> > > object reference, not an object, from `a` to `b`. (Saying the
> > > *object
> > > reference* is the value.) It's been an invaluable aid to helping
> > > people "get" object references.
> > >
> > > I'd be very sorry to hear that I was misusing a term of art. But
> > > I'd
> >
> > rather
> >
> > > know. :-)
> > >
> > > If I'm misusing "value," what should I use instead for that thing
> > > that actually gets stored in memory? How to explain the `b = a`
> > > thing with object references to beginners?
> > >
> > > This is slightly off-topic for the thread, but also not, as I
> > > spend a lot of time explaining things to JavaScript beginners, and
> > > the authors of the text being used to tell me I'm wrong are on
> > > this list. :-)
> > >
> > > Thanks,
> > >
> > > -- T.J. Crowder
> >
> > > [1]:
> > http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmasc
> > ript-l
> > an>
> > > guage-types [2]:
> > > https://en.wikipedia.org/wiki/Value_(computer_science)
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

Isiah Meadows-2

Objects contain references to their fields, but they are always passed by value. This is probably the distinction you're looking for.


On Sat, Aug 19, 2017, 16:32 Alex Kodat <[hidden email]> wrote:
While it does appear the that ECMAScript spec calls objects values, that
seems pretty unintuitive to me. My intuition is that values are immutable
(functions can and frequently do have properties added to them). The typical
distinction seems to me between values and variables. If you set a variable
to an object value how is it that the variable value changes when you change
another variable? If, on the other hand, you view object values as
references to object then changing one variable's value will never change
another's which seems a nicer view of the world. But that was T.J.'s point,
I think.

Note that strings are also generally indistinguishable from immutable
objects and are generally passed by reference under the covers but, because
they're immutable, one can safely think of the value being the actual string
rather than the reference. Numbers can be and sometimes are implemented as
immutable objects too. Like V8 implements 32-bit signed integers as pure
values and larger numbers are boxed (into hidden objects) double values.

-----Original Message-----
From: es-discuss [mailto:[hidden email]] On Behalf Of kdex
Sent: Saturday, August 19, 2017 1:55 PM
To: [hidden email]
Subject: Re: Are objects values?

I never claimed it was. I'm sure the notion of "value" that ECMAScript wants
to convey is supposed to be something along the lines of "can be bound to an
identifier".

The semantics that are then defined over primitive/non-primitive values are
a completely different matter.

On Saturday, August 19, 2017 8:44:08 PM CEST Naveen Chawla wrote:
> But references are also values. It's not a mutually exclusive thing
>
> On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
> > Yes, objects/functions are values, but they are not *primitive* values.
> >
> > The current draft uses the phrasing "object value" several times.
> >
> > Section 4.3.3 explains that objects are "members of type Object",
> > and a type is, by definition, a set of values. Therefore, objects
> > must be values.
> >
> > On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> > > I recently had an exchange which started out with my "correcting"
> > > someone
> > > who said "Functions are values" by saying "Function *references*
> > > are values. Functions are objects." He/she replied that objects
> > > are also values, and after much back and forth, cited [this part
> > > of the JavaScript
> > >
> > > spec][1]:
> > > > An ECMAScript *language type* corresponds to values that are
> > > > directly
> > >
> > > manipulated by an ECMAScript programmer using the ECMAScript language.
> >
> > The
> >
> > > ECMAScript language types are Undefined, Null, Boolean, String,
> > > Symbol, Number, and Object. An *ECMAScript language value* is a
> > > value that is characterized by an ECMAScript language type.
> > >
> > > ...and said "So objects are values."
> > >
> > > Is he/she right? [Wikpedia][2] isn't much help, at least not to
> > > me. I
> >
> > asked
> >
> > > a friend who, unlike me, did get comp sci theory at Uni, and he
> > > said "...you're not wrong, but it's very Humpty Dumpty: When I use
> > > a word, it means just what I choose it to mean -- neither more nor
less."
> > >
> > > I've used the term "value" in explanations of variables,
> > > properties, and function arguments and in particular when
> > > explaining why `b = a` copies
> >
> > an
> >
> > > object reference, not an object, from `a` to `b`. (Saying the
> > > *object
> > > reference* is the value.) It's been an invaluable aid to helping
> > > people "get" object references.
> > >
> > > I'd be very sorry to hear that I was misusing a term of art. But
> > > I'd
> >
> > rather
> >
> > > know. :-)
> > >
> > > If I'm misusing "value," what should I use instead for that thing
> > > that actually gets stored in memory? How to explain the `b = a`
> > > thing with object references to beginners?
> > >
> > > This is slightly off-topic for the thread, but also not, as I
> > > spend a lot of time explaining things to JavaScript beginners, and
> > > the authors of the text being used to tell me I'm wrong are on
> > > this list. :-)
> > >
> > > Thanks,
> > >
> > > -- T.J. Crowder
> >
> > > [1]:
> > http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmasc
> > ript-l
> > an>
> > > guage-types [2]:
> > > https://en.wikipedia.org/wiki/Value_(computer_science)
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

J Decker
In reply to this post by Naveen Chawla
note 1) 'pointer' and 'reference' are not synonymous.  Although they should be, c++ and languages evolved from it have changed the definition such that they are not.

Unfortunately; 'reference' when used by C++ people means a pointer to the value being passed; but hides the details that it is a pointer by making '.' operator behave like '->'.  transparently, and just setting 'a = new thing()' actually be '(*a) = new thing()', again, transparently.

( I really wanted to use 'reference' in the place of 'pointer' at several places in this; and have instead used 'pointer to a value' when I want to say 'a reference of a value' which, since C++ does not mean the same thing at all really)


there's a few good, diferent explanations of the terms but I'll add my own.



by there are really 3 options, pass by value, pass by reference, pass by pointer; and in this case the world should not be so black and white.

any primitive value passes by value.  1, 2,3; "apple", "banana" null, etc.  a copy of the value is passed to the called function.  Changing values does not change the original value... if you add to a string the caller does not get its string updated.

pass by pointer, a pointer to the value is passed.  Changing the pointer in the callee does not change the caller's pointer.  changing the content of what the pointer is pointing does change the content in the caller's pointer.  

pass by reference, setting a reference to a new value updates the (pointer) in the caller.  In javascript there is no good way to pass by reference.   So given the choice of 'pass by value' or 'pass by reference' the only choice is that javascript is always 'pass by value' because changing the values that are passed do not change the caller's original variables.

Wish I had more knowledge of what sort of language background you have.

in C...

pass by value  ( A pretty obvious thing)
```
void f( int a ) {
    a = 3;  // this does not change the caller's variable.
}
f( 86 );
```

pass by pointer 
```
void f( int *a ) {
   (*a) = 5; // de'referenc'ing the pointer, allows changing the value in the caller
    a = (some other pointer to int); // this would not change the caller's value.
}
int value = 3;
f( &value );
```

pass by reference  (and this, being a double pointer might be tough to wrap your head around)
```
void f( int **a ) {
    (*a[0] ) = 5; // change the value in a
    ( *a ) = New( int ); // New being a macro that allocates a new int, updates the 'reference' in caller.
   a = (some other change); // this is never reflected back to the caller.
}
int a = 5;
int *b = &a;
f( &b ); // gives the function the ability to change the pointer that is b, or the value a
```

In the third case the double-pointer is hidden in C++ so you never have the choice to try and affect the local copy of the variable, and all changes update the variables that the caller has passed.

-------------
in C# there is a parameter attribute 'ref' that you can pass pointers values.  
Structures are simple values like numbers, so if they are passed to a function, they are copied so the callee's changes to the content of the structures does not update in the caller.

(and this is not something javascript has, nor should have)
```
struct  Point { int x, int y };
Point p;

void byValue( p ) {
   p = new Point( 1,2 ); // updates to 'p' do not update the caller
   p.x = 44;  // updates to values in structures do not  update to the caller
}
Point a = { 1, 3 };
byValue( a );
```
so in the previous case, since no changes to the arguments are given to the caller, this is 'pass by value'


```
struct  Point { int x, int y };
Point p;

void byValue( Point ref p ) {
   p = new Point( 1,2 ); // updates to 'p' DO update the caller's variable
   p.x = 44;  // updates to values in structures DO update the caller's values
}
Point a = { 1, 3 };
byValue( ref a );
```
in this case, a doesn't need to be allocated by the caller, and instead the called function can create a new point, or update values in the referred to pointer.  This is much more like C++ 'reference' in which there is no way to make a change in the called function the does not update to the caller.

a class type in C# is passed by pointer (a copy of the pointer is passed) but the contents of a class can update.  Although you can also use the 'ref' parameter argument to pass the pointer to the caller's class (hmm pointer-value), so the callee can update the caller's class pointer.  (there are no pointers in c# and a C# purist will flame me for saying so, but I'm trying really hard to not use 'reference to a value; see note 1')
-----

Java behaves a lot like C#; but doesn't have structure type to cloud the issue.  Passing by reference allows the callee to update the caller's value that references a class instance.  by normal calls in that regard are pass by value, so changes to the argument value itself does not update the caller; although of course if there are values contained within the argument passed (a pointer to a class) changes to contents do propagate.... I don't know; I shouldn't talk about java.

------
So at this point, I'm going to change my rules and allow myself to say 'reference' because there are no pointers in javascript; and there are no c++-esque references.

So in javascript, a function itself is a value, it is passed by reference, updating the argument of a function never modifies the caller's values.   Updating what a parameter references does change the values in the caller's values.  

```
var thing = { a : 5 };
function f( arg ) {
   arg.a = 6; // will update the caller
   arg = { a : 9 }; // does not update the caller
}
f( thing );
```
now I have diverged a lot from the original question....(going back to read what it was)

`I recently had an exchange which started out with my "correcting" someone who said "Functions are values" by saying "Function *references* are values. Functions are objects." He/she replied that objects are also values, and after much back and forth, cited [this part of the JavaScript spec][1]:`

................. after considering my reply and the question there's actually no equate..................

```
var f = function() {
}
f.x = 3;
```
function references are values, not sure you can really have any context that you're not dealing with a reference to a function.  

functions can have properties too; so they are objects... but that's not really whether they are values or references.  basically every variable in javascript is a pointer though; not a reference or a value.




On Sat, Aug 19, 2017 at 11:44 AM, Naveen Chawla <[hidden email]> wrote:

But references are also values. It's not a mutually exclusive thing


On Sat, 19 Aug 2017, 11:32 p.m. kdex <[hidden email]> wrote:
Yes, objects/functions are values, but they are not *primitive* values.

The current draft uses the phrasing "object value" several times.

Section 4.3.3 explains that objects are "members of type Object", and a type
is, by definition, a set of values. Therefore, objects must be values.

On Saturday, August 19, 2017 7:34:45 PM CEST T.J. Crowder wrote:
> I recently had an exchange which started out with my "correcting" someone
> who said "Functions are values" by saying "Function *references* are
> values. Functions are objects." He/she replied that objects are also
> values, and after much back and forth, cited [this part of the JavaScript
>
> spec][1]:
> > An ECMAScript *language type* corresponds to values that are directly
>
> manipulated by an ECMAScript programmer using the ECMAScript language. The
> ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> Number, and Object. An *ECMAScript language value* is a value that is
> characterized by an ECMAScript language type.
>
> ...and said "So objects are values."
>
> Is he/she right? [Wikpedia][2] isn't much help, at least not to me. I asked
> a friend who, unlike me, did get comp sci theory at Uni, and he said
> "...you're not wrong, but it's very Humpty Dumpty: When I use a word, it
> means just what I choose it to mean -- neither more nor less."
>
> I've used the term "value" in explanations of variables, properties, and
> function arguments and in particular when explaining why `b = a` copies an
> object reference, not an object, from `a` to `b`. (Saying the *object
> reference* is the value.) It's been an invaluable aid to helping people
> "get" object references.
>
> I'd be very sorry to hear that I was misusing a term of art. But I'd rather
> know. :-)
>
> If I'm misusing "value," what should I use instead for that thing that
> actually gets stored in memory? How to explain the `b = a` thing with
> object references to beginners?
>
> This is slightly off-topic for the thread, but also not, as I spend a lot
> of time explaining things to JavaScript beginners, and the authors of the
> text being used to tell me I'm wrong are on this list. :-)
>
> Thanks,
>
> -- T.J. Crowder
>
> [1]:
> http://www.ecma-international.org/ecma-262/8.0/index.html#sec-ecmascript-lan
> guage-types [2]: https://en.wikipedia.org/wiki/Value_(computer_science)_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Are objects values?

Bruno Jouhier
In reply to this post by T.J. Crowder-2
FWIW I wrote a dissertation on this very topic a few years ago: https://bjouhier.wordpress.com/2010/05/15/objects-values/

tldr; 

  • Expressions have a sense and a denotation.
  • The sense of an expression accounts for its “cognitive significance”
  • The denotation of an expression is the thing that the expression denotes.
  • Two expressions may have different senses but the same denotation.
  • A variable expression is an expression that takes different denotations over time.
  • A constant expression is an expression that always has the same denotation.
  • An object is a mutable denotation.
  • A value is an immutable denotation.
  • Objects have an identity which is immutable.
  • Objects have a mutable state.
  • Numbers and physical quantities are values.
  • Dates and timestamps are values.
  • Booleans are values.
  • Characters and strings are values.
  • Sets are values.
  • A representation is an object that represents an object or a value.
  • An expression is a value that denotes an object or a value.
  • The value of an object is its identity.
  • Values are symbolic and don’t exist in the real world.
  • Objects are usually real, but not always.
This was not written in the context of a specific programming language, like JavaScript. So there is are mismatches: dates (and usually sets too) are objects in JS.
 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Are objects values?

Bruno Jouhier
In reply to this post by T.J. Crowder-2
@T.J. Going back to your original post:

According to the definitions that I gave, objects are not values (they are mutable) but they **have** a value. 
Their value is their identity which is a memory handle (a reference) in JavaScript. 
Objects are **more** than their value; they are identity + state.
When you pass or assign an object, you pass/assign the identity. The state is not copied.

The ES spec that you quote does not bluntly say that "objects are values"; it says that objects are *manipulated* as values.
I think that you can take the viewpoint that objects are not values, but that they are manipulated through their identity, which is a value.

I did not discuss functions in my write-up (was saving this for a later post that I never wrote) 
but I would classify functions as values, conceptually.
This is an area where my model disagrees with JavaScript because functions are mutable in JS: `(_ => {}).foo = 1;`. 
But this is not the only disagreement: dates are values in my model and objects in JS.

Bruno

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are objects values?

Michael Dyck
In reply to this post by T.J. Crowder-2
On 17-08-19 01:34 PM, T.J. Crowder wrote:

>
>> An ECMAScript *language type* corresponds to values that are directly
> manipulated by an ECMAScript programmer using the ECMAScript language. The
> ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
> Number, and Object. An *ECMAScript language value* is a value that is
> characterized by an ECMAScript language type.
>
> ...and said "So objects are values."
>
> Is he/she right?

Within the context of the ECMAScript spec, yes.

> I've used the term "value" in explanations of variables, properties, and
> function arguments and in particular when explaining why `b = a` copies an
> object reference, not an object, from `a` to `b`. (Saying the *object
> reference* is the value.) It's been an invaluable aid to helping people
> "get" object references.

(Note that the spec has a Reference type, but Reference values are not used
in this way.)

> I'd be very sorry to hear that I was misusing a term of art. But I'd rather
> know. :-)

I wouldn't say you're misusing a term of art, you're just using different
terminology from the spec.

> If I'm misusing "value," what should I use instead for that thing that
> actually gets stored in memory?  How to explain the `b = a` thing with
> object references to beginners?

You should just keep using whatever works. If necessary, you can say that
the terminology you're using doesn't quite match the spec's terminology, but
that's unlikely to be a problem.


Still, it's an interesting question of how to explain "the `b = a` thing" in
spec terms. It depends on the context, but typically the interesting part
will boil down to an invocation of SetMutableBinding, and then bottom out
with an action like:
     Set the bound value for 'b' (in some environment record)
     to the value that is currently bound to 'a'.
or
     Set the [[Value]] attribute of the property named 'b' (of some object)
     to the value that is currently bound to 'a'.
(I think I got that right.)
The point is that, if `a` is currently bound to an object, then the value
being bound to 'b' is (in spec terms) that object, not a reference to it or
a pointer to it or the address of it -- those terms don't exist in the spec.

To understand the spec's model (or make sense of its wording), it may help
to imagine all the various values just floating around in value space. When
an environment record binds 'b' to a value X (object or number or string,
whatever), it doesn't stuff that value into a box somewhere, it merely
creates an association between 'b' and X. (You could say that assignment
always shares values, never copies values. But it's only with objects that
the distinction is observable.)

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss