From: Jorge on
On Oct 21, 10:38 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Jorge wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Johannes Baagoe wrote:
> >> > According to the tutorial at
>
> >https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Functi...
>
> >> > Object parameters, e.g. objects, arrays and regular expressions,
> >> > are passed to functions by reference
>
> >> That is wrong.  Someone competent should use the Wiki functionality of
> >> MDC and correct it ASAP.
>
> > That's not wrong it's perfectly right
>
> No, it is not right; apparently you have not been paying attention to what I
> said.  (My posting consisted of much more than what you quoted.)
>
> "Pass by reference" has a specific meaning in programming that does not
> apply here.  "Pass by reference" means that a pointer to a memory location
> is passed so that the data at this memory location can be directly modified,
> e.g. overwritten with new data, when using this pointer.

No Pointy no. Passed by reference means that you pass a reference: no
more, no less.
More specifically, it means that what gets passed is not a copy of a
certain data (whatever the type of the data), but a reference to it.
It does not imply anything else, as you're pretending.

> (... miss-the-point nonsense removed ...)
>
> > so don't touch it unless you want to look like a fool or even worse.
>
> So more like you?

Take it easy, cocky.

> >http://en.wikipedia.org/wiki/Reference_(computer_science)
>
> You should read it and then consider the repercussions if this would apply
> to ECMAScript implementations, should all the examples given have not
> managed to convince you that it does not apply here.

Did you at last grasp the closures ?
Now you can begin (slowly, step-by-step) with references !
(With all due respect)
--
Jorge.
From: VK on
On Oct 22, 2:06 am, VK <schools_r...(a)yahoo.com> wrote:
> depending on the system load and some system
> level settings from the step 4) to step 6) the maximum delay is up to
> 180sec (3min) and rarely lesser than 60sec unless the system is on a
> crucial memory shortage so GC runs more often - or unless someone is
> slowing down everything by using left and right undocumented
> CollectGarbage() method.

I guess I forgot to number the important step #7 (CG comes and
cleans) :)

Also if anyone is wondering about anonymous objects, how do they make
it into the name table. Here the internal mechanics is the same as for
Java: if no name provided then the system generates one automatically
by classid-like rules guarantying its uniqueness for the current
session. That means btw that anonymous functions and objects vere more
instantiation expensive than named ones, but now all engine producers
have made a great deal of optimization on it.

So - maybe utterly unprofessionally but more understandably - I would
say that JavaScript operates neither with values nor with references.
The only thing it actually deals with are names from the name table.
The rest is below the language layer.
From: VK on
> > depending on the system load and some system
> > level settings from the step 4) to step 6) the maximum delay is up to
> > 180sec (3min) and rarely lesser than 60sec unless the system is on a
> > crucial memory shortage so GC runs more often - or unless someone is
> > slowing down everything by using left and right undocumented
> > CollectGarbage() method.

Sorry, that was a harsh day today so cannot get my mind together in
one post - or may it's the "Black Label" on me already :)

CollectGarbage() is undocumented but fully functional JScript
equivalent of Java's System.gc() It also doesn't remove any garbage
per se, but it trigs a unscheduled Referencer's pass by the name table
in search of GCA records. I really hope that C-grounders will not jump
on it as it was once in Java with System.gc() called on each step a la
~destructor. :) :|
From: Johannes Baagoe on
Johannes Baagoe :

>> why, exactly, do the following functions yield the shown results ?

>>   function foo(a) {a = [1];} foo(bar);          // bar[0] === 'a'
>>   function foo(a) {a[0] = 1;} foo(bar);         // bar[0] === 1
>>   function foo(a) {a = []; a[0] = 1;} foo(bar); // bar[0] === 'a'
>>   function foo(a) {a[0] = 1; a = [];} foo(bar); // bar[0] === 1

VK :

> This test set is somewhat misleading because it indirectly implies that
> something particularity special happens with objects while with
> primitives it's some other story.

Quite the opposite, I would say.

It shows that contrary to what the distinction between "call by value"
for primitive values and "call by reference" for object implies,
arguments of any type are actually passed the same way.

No reassignment to the argument inside the function will be visible
outside the function.

Modifications inside the function of an argument's *properties*
will, however, and this obviously only applies to objects, since only
objects have properties. (Arrays, etc, are special cases of objects.)

And once the argument has been overwritten inside the function,
any subsequent modification of its properties (if there are any)
will not be visible outside the function.

It is quite simple, actually, it only has to be formulated clearly,
perhaps with a few examples, and preferably without too much jargon.

--
Johannes
From: VK on
> Johannes Baagoe :
> >> why, exactly, do the following functions yield the shown results ?
> >>   function foo(a) {a = [1];} foo(bar);          // bar[0] === 'a'
> >>   function foo(a) {a[0] = 1;} foo(bar);         // bar[0] === 1
> >>   function foo(a) {a = []; a[0] = 1;} foo(bar); // bar[0] === 'a'
> >>   function foo(a) {a[0] = 1; a = [];} foo(bar); // bar[0] === 1
>
> VK :
> > This test set is somewhat misleading because it indirectly implies that
> > something particularity special happens with objects while with
> > primitives it's some other story.
>
> Johannes Baagoe :
> Quite the opposite, I would say.
>
> It shows that contrary to what the distinction between "call by value"
> for primitive values and "call by reference" for object implies,
> arguments of any type are actually passed the same way.
>
> No reassignment to the argument inside the function will be visible
> outside the function.
>
> Modifications inside the function of an argument's *properties*
> will, however, and this obviously only applies to objects, since only
> objects have properties. (Arrays, etc, are special cases of objects.)

Yes, kind of... It is like that discussion "undefined vs. undefined"
of 2006
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/060004636376462c/9b439c765cd49d54
- one pretty much understands that he's talking about but on putting
it in writing just some nonsense is coming out... Just forget about
objects whatsoever, there are names and there are names for
collections of names, now apply it to JavaScript - this is what it is
IMstrongYetHO what I tried to express in my previous posts.