«

Thomas 'PointedEars' Lahn wrote:
> Christopher J. Hahn wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
>
> > I don't see the effective difference between a reference passed by
> > value and a value passed by reference. Not in JS, anyway, which to my
> > knowledge provides no explicit means for referencing, dereferencing,
> > nor threading.
> >
> > Either way, you end up with a reference to the value.
> >
> > Functionally there's no difference, is there?
>
> There is, ref. <>
(adding news: for convenience)
>
> >> The value of the first reference variable is changed to be assigned
> >> a reference to a *new* object, and the value of the second reference
> >> variable (i.e. the object) is changed to have a new property.
> >
> > Because we're not talking pointers, but references, right?
>
> Yes.
>
>
> PointedEars


Point being, since we're talking about references, not pointers, what
difference does it make what process is gone through when it's entirely
transparent to the programmer and has the same end result?

Either way, you end up with a reference to an object.

Unless you somehow dereference the object, there's no reason to believe
that x = { } would change the thing originally referenced by x instead
of changing the value of x to be a reference to a new object.

To express it in terms of PERL, since I don't know C:
$x = {};
print $x . "\n";
print \%$x;
^D
HASH(0x15d517
HASH(0x15d517

Which is to say:
The value of $x is equal to the value of a reference to ( $x
dereferenced )

Which is to say:
It's still a reference to the same thing.

Hence func( $x ) is functionally equivalent (in terms of this
discussion) to func( \%$x ).

On the one hand you pass the value of a variable containing a
reference.
On the other you pass a reference to the thing referenced by the
variable.

How are they not functionally equivalent?

Sorry for the PERL-- I know it's not a language you've used
extensively, but JS has no syntactical equivalent, making it utterly
moot so far as I can see. Either way you end up with a reference to the
same value: the thing being referenced (object or hash), and there's
really no way to end up with anything but.

Since nobody's talking about passing around pointers, what's the issue?

Yann-Erwan Perio wrote:

> Thomas 'PointedEars' Lahn wrote:
>>>> function foo(x, y)
>>>> {
>>>> x = {bar: 42};
>>>> y.foobar = 23;
>>>> }
>>>>
>>>> var y = {}, z = {};
>>>> foo(y, z);
>>>>
>>>> does not result in (pseudocode)
>>>>
>>>> y == {bar: 42, foobar: 23}
>>> No one could ever expect that - that would be misunderstanding the
>>> basics of scoping and assignment!
>> No, if objects were 'always "passed by reference"' (as understood in a
>> language implementing pointers) as Richard stated, then x would be a
>> pointer to the object and an assignment to x would change the globally
>> defined object y. It does not, because only the reference is changed
>> to point to another object.
>
> Just to clarify : I was not referring to the pointers/references issue,
> but simply to the fact that 'y' becoming {bar:42, foobar:23} would not
> be possible,

Yes, however y == {bar: 42} would be possible with implicit dereferencing.
My bad.

> whichever perspective (reference or pointer) - y.foobar in
> the function's body would indeed apply on the object behind 'z'. This is
> why I suggested, later in my post, a change in the arguments' names.

ACK


PointedEars

Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
<snip>
>> Functions are object ...
<snip>
>>> so they're passed "by value" in all operations, and
>>> not by reference.
>>
>> Being objects they are passed by reference only.
>
> No.

You mean they are passed by value? They are not.

The value of an object is the totality of its state, so languages that
pass objects by value create a snapshot clone of the object and make
that available to the function. Javascript never does that, not even
with functions as previously suggested in this thread.

> The known pass-by-* scheme of programming languages
> implementing pointers does not apply here.

What is the point of stating that something that wasn't mentioned and
doesn't apply is irrelevant?

> A JS reference is not a pointer.

Nobody has proposed that a reference is a pointer. Nobody but you has
even mentioned pointers. That the mechanism of how an object is refereed
to by a value assigned as an object property is left to the language
implementer is irrelevant. We know that many object properties may refer
to the same object instance. We can call that a reference and never
concern ourselves with the internal details.

> Objects in JS are only available via an object reference.

So they can only be available inside a function to which they are
presented as an argument as a reference to an object.

> One could say that those references are passed to
> methods by value

Yes you could. The odds are very good that a value that represents some
sort of reference to an object is actually copied in the process of
passing a reference to an object as a function argument. Thus the
reference itself is passed by value, but passing the value of a
reference is equivalent to passing the object referred to by reference
(the copy of the value of the reference will still refer to the same
object instance).

> and that value is the object.

You would be better off saying that the value of a reference to an
object is a reference to an object.

Thinking in terms of the value of an object property that refers to an
object as being that object is going to cause confusion as soon as it is
apparent that many properties refer to the same object and so that many
values in diverse locations are all that one object (just writing it
down makes it a self-evident that it is confusing).

A great deal of what makes OO useful is that it renders abstract notions
tangible. The very use of the word 'Object' to describe something so
nebulous that (in javascript at least) we don't even care how it
manifests itself inside the computer is an indication of that. An object
instance is just that; one entity, which is created, has a life span and
is disposed off (in some way). It makes much more sense to think of many
values referring to that one object than of many values being that one
object.

> If you see it this way, it is quite clear why
>
> function foo(x, y)
> {

So when execution reaches this point the 'x' property of the function's
execution context's activation/Variable object holds a value that is a
reference to the object that is also referred to by the value of the
global 'y' variable and its 'y' property refers to the same object as
the object referred to by the global 'z' variable.

> x = {bar: 42};

And now the 'x' property of the Activation/Variable object has been
assigned a reference to a new object.

> y.foobar = 23;

While the reference held in the 'y' property has been used to identify
the object that is also referred to by the global 'z' variable and
assign a new value to one of its properties.

> }
>
> var y = {}, z = {};
> foo(y, z);
>
> does not result in (pseudocode)
>
> y == {bar: 42, foobar: 23}

There was no reason to ever expect that it would. Assuming you are
referring to the object referred to by the global 'y' variable then no
operations have been performed that could influence it.

> but in
>
> y == {}
> z == {foobar: 23}
>
> The value of the first reference variable is changed to be
> assigned a reference to a *new* object,

I assume you mean the first reference _parameter_ here, as it is the
value of the parameter (as manifest in the corresponding named property
of the Activation/variable object) that was modified to be a reference
to a new object.

> and the value of the second reference variable (i.e.
> the object) is changed to have a new property.

The state of the object was changed, indirectly, via the reference to
the object passed to the function as its second parameter.

It is significant that even imprecisely worded you are forced to express
the behaviour of the code in terms of references to objects. In
javascript all objects are passed by reference.

Richard.

"Random" <> writes:

> Either way, you end up with a reference to an object.

We're back to the defintion of call-by-value and call-by-reference now.

In call-by-value, you pass a value. The parameter is a new variable
referring to the value that was passed.

In call-by-reference, you don't pass a reference to the value, but to
a *variabel*. The parameter becomes an alias of the variable that
was passed. E.g., in C#, using reference parameters:

---
static void Foo(ref int x) {
x = 42;
}

static void Bar() {
int baz = 37;
Foo(ref baz);
Console.WriteLine("{0}", baz); // Outputs "42"
}
---

Call-by-reference means that a call can change the value of a variable
that is not in scope from the called function.


Javascript only has call-by-value. Some values are called "references",
but that should not be confuzed with the way parameters are passed.


> Unless you somehow dereference the object, there's no reason to believe
> that x = { } would change the thing originally referenced by x instead
> of changing the value of x to be a reference to a new object.

In call-by-reference, it would change what "x" refers to. It will not
change the previous *value* that "x" referred to, only *what* value it
refers to.

> To express it in terms of PERL, since I don't know C:
> $x = {};
> print $x . "\n";
> print \%$x;
> ^D
> HASH(0x15d517
> HASH(0x15d517
>
> Which is to say:
> The value of $x is equal to the value of a reference to ( $x
> dereferenced )
>
> Which is to say:
> It's still a reference to the same thing.

But try this in Perl:
---
#!perl
sub foo {
my ($x) = @_;
$$x = 42;
}

sub bar {
my $baz = 37;
foo(\$baz);
print $baz;
}

bar();
---

This is explicit passing of a reference to a variable. In languages
like C#, the support for that is more indirect (references to
variables are not first class values there).

> On the one hand you pass the value of a variable containing a
> reference.
> On the other you pass a reference to the thing referenced by the
> variable.

And both are passed by value. (If passing by reference, you pass
an l-value, not an r-value.)

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"Richard Cornford" <> writes:

> Thomas 'PointedEars' Lahn wrote:
>> Richard Cornford wrote:

>>> Being objects they are passed by reference only.
>>
>> No.
>
> You mean they are passed by value? They are not.

No, their reference is passed by value. Using the word "passed by
reference" suggests (well, duh pass by reference semantics, which
it doesn't have.

> The value of an object is the totality of its state,

I would include its identity too, which is what separates objects from
structs.

> so languages that pass objects by value create a snapshot clone of
> the object and make that available to the function.

.... but when you include identity in the value of the object, then
that would not be correct value passing semantics either.

In fact, objects are not denotable or expressible values (they can't
be assigned to a variable, and you can't write an expression that
evalutes to an object). Only *references* to objects are denotable
and expressible values. The value of an object literal expression
is a reference to the object.

(That objects are neither denotable nor expressible goes for all other
OO languages that I know. (Which is not too many, but still ...

Objects are used (has messages sent to them, to be *really* OO)
through their references.

References are passed by value, as all other values in Javascript.


> but passing the value of a reference is equivalent to passing the
> object referred to by reference (the copy of the value of the
> reference will still refer to the same object instance).

That is not the traditional meaning of "passing by reference". In
that, you pass an l-value, really a reference to a variable, not to
its value. The called function has an alias of the vairable, and can
change its value.

> You would be better off saying that the value of a reference to an
> object is a reference to an object.

To be absolutely pedantic:
Expressions have values and variables refer to values.
If a variable refers to a reference to an object, then the value of
the expression consisting of that variable is the reference to the
object.

When passing the variable by reference, that called function has
access to the variable, and can change what it refers to. The formal
parameter of the function becomes an alias of the variable.

When passing a value by reference, the formal parameter of the
function becomes a new variable referring to the value that was
passed.


> It is significant that even imprecisely worded you are forced to express
> the behaviour of the code in terms of references to objects. In
> javascript all objects are passed by reference.

In Javascript, all object references are passed by value. Objects are
never passed at all.

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Lasse Reichstein Nielsen wrote:
> "Richard Cornford" <> writes:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> Richard Cornford wrote:
>
> >>> Being objects they are passed by reference only.
> >>
> >> No.
> >
> > You mean they are passed by value? They are not.
>
> No, their reference is passed by value. Using the word "passed by
> reference" suggests (well, duh pass by reference semantics, which
> it doesn't have.
>
> > The value of an object is the totality of its state,
>
> I would include its identity too, which is what separates objects from
> structs.
>
> > so languages that pass objects by value create a snapshot clone of
> > the object and make that available to the function.
>
> ... but when you include identity in the value of the object, then
> that would not be correct value passing semantics either.
>
> In fact, objects are not denotable or expressible values (they can't
> be assigned to a variable, and you can't write an expression that
> evalutes to an object). Only *references* to objects are denotable
> and expressible values. The value of an object literal expression
> is a reference to the object.
>
> (That objects are neither denotable nor expressible goes for all other
> OO languages that I know. (Which is not too many, but still ...
>
> Objects are used (has messages sent to them, to be *really* OO)
> through their references.
>
> References are passed by value, as all other values in Javascript.
>
>
> > but passing the value of a reference is equivalent to passing the
> > object referred to by reference (the copy of the value of the
> > reference will still refer to the same object instance).
>
> That is not the traditional meaning of "passing by reference". In
> that, you pass an l-value, really a reference to a variable, not to
> its value. The called function has an alias of the vairable, and can
> change its value.

[really liberal snipping]

> /L
> --
> Lasse Reichstein Nielsen -
> DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
> 'Faith without judgement merely degrades the spirit divine.'

Thank you for that really excellent explanation. Basically, my
understanding of the term "pass by reference" is what's incorrect.

Given that explanation, I can see why it doesn't apply here, since
we're not actually passing lvalues, just references.

Thanks!