Closure bug

[Ry Nohryb]

C is a bad example since it doesn't have reference parameters at all
(nor objects, for that matter).

C is a perfect example imo because it's the grandfather of JS, and
because I'm trying hopelessly to point out that the terminology used
for over 30 years in C wrt passing by reference is applicable to JS as
well.

 

[Dmitry A. Soshnikov]

what
you're doing here is just a convoluted (and inefficient, btw) way of
doing this:

void foo (struct Object* oRefCopy) {
oRefCopy->x = 100;
oRefCopy->y = 200;
}

Oh, really? :O (Thanks, I know it. And the goal was to show exactly how
_assignment_ will change the memory block, but not only overloaded
"sugar" (which is known for all current speakers I hope) for accessing
properties of a structure via a pointer).

And, unless you resort to type casting, you *won't* be able put
anything other (different) than exactly an "Object" type into o, just
as happens in JS: a reference to an object (in JS) will always point
to that object: you can modify it, but you can't make it be anything !
== than the object that it is.

I didn't get it. Type casting is relevant of course when we deal with C
in this case. But what do you mean in JS? Show me please an example.

Dmitry.

 

[Richard Cornford]

So the the semantics of pass-by-value ("by-copy") do *not*
necessarily imply a copy. What can I say ? Brilliant !
You're right, afaics. There's another way of putting it:
(*) "you can cheat if you don't get caught"

<snip>

Cheating isn't even a consideration if you are not breaking any of the
rules in the first place.

The broader problem here is coming up with some (preferably simple and
concise) formulation that will inform people who are not
(sufficiently) familiar with what javascript does (with regard to
function/method calls) about what they can expect (and why). To that
end there is an appeal in explanations that draw parallels with the
behaviour in other languages (though obviously that is of limited
value for total newcomers (or even those unfamiliar with the languages
in question (or sufficiently similar languages))).

I have read, and/or been involved in, numerous discussions of the
terminology that gets applied to these explanations, such as "pass-by-
value", pass-by-reference", "pointer", etc. Unfortunately, there
appear to be as many valid reasons for using each as valid reasons for
their being inapplicable to javascript (or in extreme cases too
esoteric/obscure to be usefully employed in explaining javascript).
So round and round the arguments go.

It makes me think that a different approach might be better. Possibly
an approach that does not stray too far from ECMA 262; where no real
attempt is made to resolve "value" and an object can be (or is) just a
"value". That will take some thinking about, and probably two or three
attempts to get right.

Richard.

 

[Ry Nohryb]

<snip>

Cheating isn't even a consideration if you are not breaking any of the
rules in the first place.

The broader problem here is coming up with some (preferably simple and
concise) formulation that will inform people who are not
(sufficiently) familiar with what javascript does (with regard to
function/method calls) about what they can expect (and why). To that
end there is an appeal in explanations that draw parallels with the
behaviour in other languages (though obviously that is of limited
value for total newcomers (or even those unfamiliar with the languages
in question (or sufficiently similar languages))).

I have read, and/or been involved in, numerous discussions of the
terminology that gets applied to these explanations, such as "pass-by-
value", pass-by-reference", "pointer", etc. Unfortunately, there
appear to be as many valid reasons for using each as valid reasons for
their being inapplicable to javascript (or in extreme cases too
esoteric/obscure to be usefully employed in explaining javascript).
So round and round the arguments go.

It makes me think that a different approach might be better. Possibly
an approach that does not stray too far from ECMA 262; where no real
attempt is made to resolve "value" and an object can be (or is) just a
"value". That will take some thinking about, and probably two or three
attempts to get right.

No doubt.

What I'm 100% against is the new, almost fundamentalist, revisionist
and disrespectful attempt at re-definition of the meaning of the
simple and well established over 30 years ago and commonly used term
"pass-by-reference", by young newbie wannabe programmers (in funny t-
shirts and wearing colorful horn-rimmed eyeglasses), obviously due to
their *total*ignorance* of not only the C language but the *history*
and the previous *well*established*long-standing*terminology*. Grrr.

 

[Ry Nohryb]

Richard Cornford :


I found Liskov's "call-by-sharing" terminology very handy.
http://en.wikipedia.org/wiki/Evaluation_strategy

<quote>
However, the term "call by sharing" is not in common use; the
terminology is inconsistent across different sources. For example, in
the Java community, they say that Java is pass-by-value, whereas in
the Ruby community, they say that Ruby is pass-by-reference, even
though the two languages exhibit the same semantics.
</quote>

C: 1972, Java, Ruby, JS, PHP: 1995. Gimme a break.

 

[Ry Nohryb]

Oh, really? :O (Thanks, I know it. And the goal was to show exactly how
_assignment_ will change the memory block, but not only overloaded
"sugar" (which is known for all current speakers I hope) for accessing
properties of a structure via a pointer).


I didn't get it. Type casting is relevant of course when we deal with C
in this case. But what do you mean in JS? Show me please an example.

There's nothing to show, as there's no type-casting in JS

 

[Dmitry A. Soshnikov]

There's nothing to show, as there's no type-casting in JS

Then the question about type casting is closed and is irrelevant
regarding to JS. I mean, there was no reason to mention it. Did I
understand all correctly now?

And drawing parallel with C's pointers (with the only mentioned above
difference) and JS's strategy is still OK, yes.

Dmitry.

 

[John G Harris]

while you can observe the
modification to an object and conclude that there must be some
'referencing' mechanism that has all values that are objects
'referring' to the single object

<snip>

Have you found the words in ECMA 262 that actually say that? If you have
please tell me where as I haven't. It seems to be 'common knowledge' but
not explicit.

John

 

[Ry Nohryb]

Then the question about type casting is closed and is irrelevant
regarding to JS. I mean, there was no reason to mention it. Did I
understand all correctly now?

Well, no. The ability to type cast, while unrelated to pointers,
references and parameter passing mechanisms, is what allows C to
shoehorn into a reference a different thing than what it was. Given
that JS provides no such features (neither type-casting nor
shoehorning a different type into a given reference), it's not fair to
say that C pointers and/or its parameter passing mechanism allow a
feature (what you call "one important difference") that JS lacks,
because it's not a feature of the pointers/reference passing mechanism
but that of the type casting C language feature.

(Hmm, not even sure how well worded that is

And drawing parallel with C's pointers (with the only mentioned above
difference) and JS's strategy is still OK, yes.

It's fully equal, identical, if you leave aside type casting: there's
not any difference at all.

 

[Richard Cornford]

On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote:



<snip>

Have you found the words in ECMA 262 that actually say
that? If you have please tell me where as I haven't. It
seems to be 'common knowledge' but not explicit.

The words that actually say what exactly? There are no words in the
spec that say "can ... conclude", the ability to do that as a result
of the observation is evidently a fact (as at least one person has
done so).

Richard.

 

[Lasse Reichstein Nielsen]

On May 19, 4:54 pm, Ry Nohryb wrote:


How can you tell? Specifically, how can you tall that primitives are
not implemented as structures somewhere in memory and that the values
assigned to object properties/valuables are not references to those
structures; that copying a primitive 'value' from one variable to
another does not actually involve copying a reference?

I sure hope you can't since that's probably how all implementations
handle strings (and some handle large numbers that way too).

/L

 

[Ry Nohryb]

I sure hope you can't since that's probably how all implementations
handle strings (and some handle large numbers that way too).

Does a large number occupy any more than a small one ?

 

[Richard Cornford]

I sure hope you can't since that's probably how all
implementations handle strings (and some handle large
numbers that way too).

Yes, an implementation in a language that has no string primitives
(such as Java) would have little choice but employ some sort of object
to represent javascript's string primitives. On the other hand,
javascript implemented in javascript (i.e. Narcissus) might use
javascript's string primitives to represent javascript string
primitives (probably best not to start thinking about the implications
of that, but at least in that implementation we can be sure that
'pointers' to memory addresses are not being used, as there are none
to use).

Richard.

 

[Dr J R Stockton]

In comp.lang.javascript message <timstreater-9A1608.13415819052010@news.
individual.net>, Wed, 19 May 2010 13:41:58, Tim Streater

Which is why:

function test (o) { o = null; }

does *not* change p, whereas:

function test (o) { o.j= "Simpson"; }

*does* change the *object* that p points at. While test is running,
there are two pointers to the object, and only one before and after (or
at some point after, possibly).

It does not change the object. It does change the contents of the
object.

 

[Richard Cornford]

Does a large number occupy any more than a small one ?

Javascript uses 64 bit floating point numbers, so they must occupy at
least 8 bytes (and probably more in reality as javascript values need
to know, for example, what type they are in case they get asked).
However, it has been pointed out that there are cases where the
complier can observe variables, being assigned number values, and
being employed in such a way as to, say, guarantee that a 32 bit
signed integer could do the job (i.e. a loop counter starting at zero
and counting up to some known value). This opens the door to
optimisations where (alternative,) smaller number types could be used
to save memory and processing time. This is a case where you can cheat
if you can know you will get away with it. So a smaller number
(sometimes) could occupy less space than a large one.

Richard.

 

[Ry Nohryb]

Ry Nohryb :


Well, the "call-by-reference" vs. "call-by-value" terminology is
even older, it comes from the great FORTRAN vs. Algol wars. (In early
versions of FORTRAN, one could actually change the value of constants,
by something like CALL INCREMENT(1) if I remember rightly.)

Most modern languages use neither FORTRAN's pure call-by-reference,
nor pure call-by-value, where even huge data structures are copied
entirely, like in Algol and its successors like Pascal (unless the formal
parameter is preceded by the `var` keyword).

What they do use deserves a name, IMHO, since it is a very important
point to understand. "Call by sharing" may not be the best possible
wording, but it was proposed by a lady with a Turing award. I think
it may serve until someone comes up with a better idea.

It's ok to call it call-by-sharing but it's not ok to say that objects
aren't being passed by reference.

 

[Tim Streater]

You could and it did. When first writing FORTRAN in 1967 I got warned
about this (and other FORTRAN-y bits of b/s)

It's ok to call it call-by-sharing but it's not ok to say that objects
aren't being passed by reference.

The object isn't being passed at all. A copy of the pointer to it is. By
value.

 

[Tim Streater]

Javascript uses 64 bit floating point numbers, so they must occupy at
least 8 bytes (and probably more in reality as javascript values need
to know, for example, what type they are in case they get asked).
However, it has been pointed out that there are cases where the
complier can observe variables, being assigned number values, and
being employed in such a way as to, say, guarantee that a 32 bit
signed integer could do the job (i.e. a loop counter starting at zero
and counting up to some known value).

You mean e.g. and not i.e.

 

[Lasse Reichstein Nielsen]

Does a large number occupy any more than a small one ?

Not just the plain size, but some implementations have optimizations
for small *integers*, with a fallback to a full double value for the
values that can't be optimized.
See, e.g.,
http://trac.webkit.org/browser/trunk/JavaScriptCore/runtime/JSImmediate.h#L75
http://code.google.com/p/v8/source/browse/trunk/src/objects.h#717

/L

 

[Eleandor]

Wow, I had no idea this would receive so many replies... Even though
most of them are irrelevant to my question.

First some apologies:
I always use \t for indendation in my editor, so I'm sorry for not
following the expected indendation rules as I wasn't aware of them.
Neither was I aware that "self" is an alias for "window". Won't use it
again, clearly it causes too much confusion. For all I care though, I
don't see much use for "self"...
Sorry for omitting the DOCTYPE & title elements. It's only a testpage
and I didn't think it would cause any harm in a browser like FF or
chrome.

Another note: I'm not a javascript expert (as you might have noticed
from the fact I'm not very familiar with the way closures work in
javascript), and I'm not really interested in IE compatibility. At
this point pretty much everything I do consistently breaks in IE,
which is probably not a surprise because I'm using popular HTML5
elements anyway.

To conclude this message, I now think I pretty much understand how
closures work in ecmascript. I still find it pretty unintuitive
though, given the c-like syntax... Reminds me too much of c when it's
in fact quite a different language.

It does not change the object. It does change the contents of the object.

It does change the object... p and o aren't objects, they're
references. By modifying o.j you're changing the object that o
references.
Changing the object and changing the contents of the object is
essentially saying the same thing. What you're not changing are the
values of o and p, which means they still reference the same object.
But the object itself has been modified.

I'm thinking you two are just saying the same thing, but clearly
disagree on the vocabulary...