«

Christopher J. Hahn wrote:
> Richard Cornford wrote:
> > Christopher J. Hahn wrote:
> > > Razzbar wrote:
> > >> What's especially neat is that you can assign a new
> > >> function to the top window from the iframe, then load
> > >> another document in the iframe, and the top window's
> > >> new function is still available.
> > >
> > > If I'm right, I believe that's because functions are
> > > primitive data types in JS, like strings and numbers,
> >
> > Functions are object in javascript. And like all other objects they can
> > have named properties added to them, and assigned values, at any time.
> >
> > > so they're passed "by value" in all operations, and
> > > not by reference.
> > <snip>
> >
> > Being objects they are passed by reference only.
> >
> > Richard.
>
> Not to be argumentative, but if they are passed by reference only then
> could you explain why the referant isn't freed, causing an error in the
> case described by Razzbar?
>
> I've been too busy to actually test the case, mind you, but I'm fairly
> sure he's correct.

Richard,
Incidentally I did manage a *very* small test case and found that
by-reference-only appeared to be correct, though I didn't use frames or
anything.

But I really would appreciate it if you could explain to me why the
function object doesn't appear to be freed upon navigation like other
objects which are also members of the child window object. I think it
would clear up a lot of my confusion on this matter.

Martin Honnen wrote:

> What does pass by reference or value have to do with the case of frames?
> If you have a global variable in one frame then it is a property of the
> window object of the frame thus if the iframe document does
> parent.varName = someExpression
> then a global variable in the parent window is set and that variable
> does not change if a new document is loaded into the iframe as the
> iframe has its own window object with its own variables.

Hmm... the iframe's document defines a function. The iframe's document
is a child of the iframe's window, so the iframe's function is part of
the of the iframe's window, which is part of the parent window...

> Whether that expression evaluates to a primitive value or a function
> object does not matter at all, there is not even a method or function
> with arguments involved where the term passing by reference or value
> makes sense.

But the question is, if top.foo() is a reference* to the foo() defined
in a document that has gone bye-bye, why does top.foo() still work?

If top.foo() = foo() //in the iframe's temporary document was an
assignment by value, it would make sense that it persists.

But if that's an assignment by reference, what would it be pointing to
after the defining document has changed?

Christopher J. Hahn wrote:
> Richard Cornford wrote:
>> Christopher J. Hahn wrote:
>>> If I'm right, I believe that's because functions are
>>> primitive data types in JS, like strings and numbers,
>>
>> Functions are object in javascript. And like all other
>> objects they can have named properties added to them,
>> and assigned values, at any time.
>>
>> > so they're passed "by value" in all operations, and
>> > not by reference.
>> <snip>
>>
>> Being objects they are passed by reference only.
>>
>> Richard.
>
> Not to be argumentative,

Don't worry about being argumentative.

> but if they are passed by reference only then could you
> explain why the referant isn't freed, causing an error in
> the case described by Razzbar?

Superficial testing is the most likely explanation of the behaviour
described. The bottom line is that calling a function that has been
defined in a frame that has unloaded via a reference to that function in
another frame is not going to work cross-browser. Confidence acquired by
only testing browsers where it does work is no indicator of reliability.

Consider what would happen where it does work. Think about garbage
collection. If the containing frame refers to a function that originates
in (and so in some sense belongs to) another frame's global object then
that function should not be able to be garbage collected when the
contents of that other frame unload. And as the function's scope chain
refers to the global object then that global object should not be
garbage collectable, and as the global object refers to the document
(and indirectly to its contents) the document should not be garbage
collectable, and so on. So where it works it is a brilliant way of tying
up a big chunk of memory in exchange for the ability to use what is
potentially a tiny function. (And might even result in talk of memory
leaks, where the memory consumption would in reality be the expected
consequences of behaviour being specifically programmed).

However, the execution environment of an unloaded frame is (to some
degree or another, in different browsers) dismantled and functions and
objects referred to by properties in different frames may start
producing errors if used. that is certainly the case for functions in
some versions of Windows IE 6, and if it doesn't work in Windows IE 6
then it has no potential application in a commercial project.

That this should happen, and that the results should differ considerably
between browsers (and browser versions) is not particularly surprising
as ECMAScript is designed for one global object, and one execution
environment, rather than multiple interacting environments. There is
simply no specified mechanism for the interactions between environments.

> I've been too busy to actually test the case, mind you,
> but I'm fairly sure he's correct.

Do try it.

Richard.

Richard Cornford wrote:
> Christopher J. Hahn wrote:
> > Richard Cornford wrote:
> >> Christopher J. Hahn wrote:
> >>> If I'm right, I believe that's because functions are
> >>> primitive data types in JS, like strings and numbers,
> >>
> >> Functions are object in javascript. And like all other
> >> objects they can have named properties added to them,
> >> and assigned values, at any time.
> >>
> >> > so they're passed "by value" in all operations, and
> >> > not by reference.
> >> <snip>
> >>
> >> Being objects they are passed by reference only.
> >>
> >> Richard.
> >
> > Not to be argumentative,
>
> Don't worry about being argumentative.

Courtesy is a pretense with a purpose.

> > but if they are passed by reference only then could you
> > explain why the referant isn't freed, causing an error in
> > the case described by Razzbar?
>
> Superficial testing is the most likely explanation of the behaviour
> described. The bottom line is that calling a function that has been
> defined in a frame that has unloaded via a reference to that function in
> another frame is not going to work cross-browser. Confidence acquired by
> only testing browsers where it does work is no indicator of reliability.
>
> Consider what would happen where it does work. Think about garbage
> collection. If the containing frame refers to a function that originates
> in (and so in some sense belongs to) another frame's global object then
> that function should not be able to be garbage collected when the
> contents of that other frame unload. And as the function's scope chain
> refers to the global object then that global object should not be
> garbage collectable, and as the global object refers to the document
> (and indirectly to its contents) the document should not be garbage
> collectable, and so on. So where it works it is a brilliant way of tying
> up a big chunk of memory in exchange for the ability to use what is
> potentially a tiny function. (And might even result in talk of memory
> leaks, where the memory consumption would in reality be the expected
> consequences of behaviour being specifically programmed).

But there are other functionalities inherent in the language itself
that allow for remote creation of objects without resorting to the
ill-considered and clumsy implementation implied by the behavior to
which you're referring. There is no reason for a JS implementor to make
garbage collection quirky.



> However, the execution environment of an unloaded frame is (to some
> degree or another, in different browsers) dismantled and functions and
> objects referred to by properties in different frames may start
> producing errors if used. that is certainly the case for functions in
> some versions of Windows IE 6, and if it doesn't work in Windows IE 6
> then it has no potential application in a commercial project.
>
> That this should happen, and that the results should differ considerably
> between browsers (and browser versions) is not particularly surprising
> as ECMAScript is designed for one global object, and one execution
> environment, rather than multiple interacting environments. There is
> simply no specified mechanism for the interactions between environments.

There's no reason the window object need be considered the top-level
object internally, so there's no reason for implementors to consider
the window to be an environment as opposed to another object in the
scope chain.

The problem seems to stem from the ambiguity of the relationship
between a document and its window. It would seem more intuitive (to me,
anyway) that variables and objects created by a document should be
properties of the document, rather than the window. Again, this is
obviously not the language's fault as (to my knowledge), the language
itself doesn't provide window or document objects.

This would be another point wehere I would like to see the W3C weigh
in.



> > I've been too busy to actually test the case, mind you,
> > but I'm fairly sure he's correct.
>
> Do try it.
>
> Richard.

The ability to do things that I believe I should not expect to work is
something that I try to forget about, as it lends itself to bad
practice in other languages and/or past or future versions or other
implementations of the same language (like I mentioned with PERL's
automatic return of the value of the last expression in a function). To
me, thought should be just as portable as code.

Thanks for that excellent answer, Richard.




Sorry if any of what I've said makes little sense-- I've been pretty
swamped and my mind is scattered across many things at once. This week
I am thinking in PERL::threads+C. Next week I'll be thinking in
PHP/C+HTML again. The week after it'll be JS+PHP+NNTP+HTML, with some
MySQL on the side.

Richard Cornford wrote:

> Christopher J. Hahn wrote:
>> Razzbar wrote:
>>> What's especially neat is that you can assign a new
>>> function to the top window from the iframe, then load
>>> another document in the iframe, and the top window's
>>> new function is still available.
>>
>> If I'm right, I believe that's because functions are
>> primitive data types in JS, like strings and numbers,
>
> Functions are object in javascript. And like all other objects they can
> have named properties added to them, and assigned values, at any time.
>
>> so they're passed "by value" in all operations, and not by reference.
> <snip>
>
> Being objects they are passed by reference only.

No. The known pass-by-* scheme of programming languages implementing
pointers does not apply here. A JS reference is not a pointer.

Objects in JS are only available via an object reference. One could say
that those references are passed to methods by value and that value is the
object. If you see it this way, it is quite clear why

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}

but in

y == {}
z == {foobar: 23}

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.


PointedEars

Thomas 'PointedEars' Lahn wrote:

<snip>

> 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!

> but in
>
> y == {}
> z == {foobar: 23}

That's true, but your example is, IMHO, too obscure to serve as a clear
demonstration of whichever point.

---
function foo(a, b) {
a = {bar: 42};
b.foobar = 23;
}

var y = {p:"y"}, z = {p:"z"};
foo(y, z);
---

> 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.

Explaining in what 'y' consist in the end, and why, would certainly help
to provide some insight on the way references and objects work in
javascript.


Regards,
Yep 'passing by reference'.

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.

>> but in
>>
>> y == {}
>> z == {foobar: 23}
>
> That's true, but your example is, IMHO, too obscure to serve as a clear
> demonstration of whichever point.
>
> ---
> function foo(a, b) {
> a = {bar: 42};
> b.foobar = 23;
> }
>
> var y = {p:"y"}, z = {p:"z"};
> foo(y, z);
> ---

OK, that's more clear. However, if one understood scoping and the
pass-by-reference scheme, he would also understand my example.

>> 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.
>
> Explaining in what 'y' consist in the end, and why, would certainly help
> to provide some insight on the way references and objects work in
> javascript.

[x] done


PointedEars

Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>
> > Christopher J. Hahn wrote:
> >> Razzbar wrote:
> >>> What's especially neat is that you can assign a new
> >>> function to the top window from the iframe, then load
> >>> another document in the iframe, and the top window's
> >>> new function is still available.
> >>
> >> If I'm right, I believe that's because functions are
> >> primitive data types in JS, like strings and numbers,
> >
> > Functions are object in javascript. And like all other objects they can
> > have named properties added to them, and assigned values, at any time.
> >
> >> so they're passed "by value" in all operations, and not by reference.
> > <snip>
> >
> > Being objects they are passed by reference only.
>
> No. The known pass-by-* scheme of programming languages implementing
> pointers does not apply here. A JS reference is not a pointer.
>
> Objects in JS are only available via an object reference. One could say
> that those references are passed to methods by value and that value is the
> object. If you see it this way, it is quite clear why

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?


> 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}
>
> but in
>
> y == {}
> z == {foobar: 23}

Even given the way of thinking that the referenced object is being
passed by reference, this is equally clear.

The only difference (and I wouldn't call it a "real" difference) is
that, by saying it is being passed by reference, there's an implied
step of dereferencing, which I'm assuming doesn't actually occur.


> 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?


> PointedEars

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. <>

>> 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

Thomas 'PointedEars' Lahn wrote:

Hi,

<snip>

>>> 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, 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.

<snip>


Regards,
Yep.