Scope of constructed objects

[Christopher Benson-Manica]

Just to make sure I'm on the right track...

function getADate() {
return new Date();
}

function foo() {
var bar=getADate();
alert( bar );
}

This doesn't work as one might expect because the date constructed by
getADate() is destroyed once the function returns, meaning that bar
is a reference to a destroyed object when alert() is called. Is that
correct?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Paul R]

Re: Scope of constructed objects

Christopher Benson-Manica wrote:[color=blue]
> Just to make sure I'm on the right track...
>
> function getADate() {
> return new Date();
> }
>
> function foo() {
> var bar=getADate();
> alert( bar );
> }
>
> This doesn't work as one might expect because the date constructed by
> getADate() is destroyed once the function returns, meaning that bar
> is a reference to a destroyed object when alert() is called. Is that
> correct?
>[/color]
Depends what one "expects"! Your function returns a Date object complete
with all its methods and properties, initialised to the date and time it
was created. This object won't be destroyed until your program's stopped
referring to it, but nor (perhaps confusingly) will the time and date be
automatically refreshed.

[Lee]

Re: Scope of constructed objects

Christopher Benson-Manica said:[color=blue]
>
>Just to make sure I'm on the right track...
>
>function getADate() {
> return new Date();
>}
>
>function foo() {
> var bar=getADate();
> alert( bar );
>}
>
>This doesn't work as one might expect because the date constructed by
>getADate() is destroyed once the function returns, meaning that bar
>is a reference to a destroyed object when alert() is called. Is that
>correct?[/color]

No. It works as I expect, alerting the current date and time.
Local variables are destroyed once a function returns, but there
are no local variables in getADate(). The Date object survives
because there is still a reference to it. Once foo() returns,
the last reference to that Date object is destroyed and it will
be subject to garbage collection.

[Christopher Benson-Manica]

Re: Scope of constructed objects

Lee <REM0VElbspamtr ap@cox.net> spoke thus:
[color=blue]
> No. It works as I expect, alerting the current date and time.
> Local variables are destroyed once a function returns, but there
> are no local variables in getADate(). The Date object survives
> because there is still a reference to it. Once foo() returns,
> the last reference to that Date object is destroyed and it will
> be subject to garbage collection.[/color]

So why, then, does a reference to a variable in another window become
invalid when that window is destroyed?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Duncan Booth]

Re: Scope of constructed objects

Christopher Benson-Manica wrote:
[color=blue]
> Lee <REM0VElbspamtr ap@cox.net> spoke thus:
>[color=green]
>> No. It works as I expect, alerting the current date and time.
>> Local variables are destroyed once a function returns, but there
>> are no local variables in getADate(). The Date object survives
>> because there is still a reference to it. Once foo() returns,
>> the last reference to that Date object is destroyed and it will
>> be subject to garbage collection.[/color]
>
> So why, then, does a reference to a variable in another window become
> invalid when that window is destroyed?
>[/color]
It doesn't. References never become invalid although the objects they
reference may mutate and stop offering functionality they once had.

You can't have a reference to a variable. You can have a reference to an
object, and the object will exist until there is no way to reference it
from your program.

If you make a reference to an object in another window, the object will
exist beyond the lifetime of the window so long as your reference is still
reachable from your code.

[Christopher Benson-Manica]

Re: Scope of constructed objects

Duncan Booth <duncan.booth@i nvalid.invalid> spoke thus:
[color=blue]
> It doesn't. References never become invalid although the objects they
> reference may mutate and stop offering functionality they once had.[/color]

Why would the object mutate? I'm getting a little bit confused here.
[color=blue]
> If you make a reference to an object in another window, the object will
> exist beyond the lifetime of the window so long as your reference is still
> reachable from your code.[/color]

Define "still reachable" - I tested this exact situation, and a Date
object from another window seemed to "mutate" (it was still an object,
but it didn't appear to be a Date object any more).

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Re: Scope of constructed objects

Duncan Booth <duncan.booth@i nvalid.invalid> spoke thus:
[color=blue]
> If you make a reference to an object in another window, the object will
> exist beyond the lifetime of the window so long as your reference is still
> reachable from your code.[/color]

Here's the test I performed - the Date object is intact before the
window closes, but afterward it's mutated into something else...

<html>
<head>
<script type="text/javascript">
var date, pwin;
function clickIt() {
alert( date );
}
function setDate( adate ) {
date=adate;
alert( date );
pwin.close();
}
function pop() {
pwin=window.ope n( '' );
pwin.document.w riteln( '<html>'+
' <head>'+
' <script type="text/javascript">'+
' var date=new Date();'+
' window.opener.s etDate( date );'+
'<\/script><\/head><\/html>' );
}
</script>
</head>
<body>
<input type="button" value="click" onclick="clickI t()"><br>
<input type="button" value="pop" onclick="pop()" >
</body></html>

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Duncan Booth]

Re: Scope of constructed objects

Christopher Benson-Manica wrote:
[color=blue]
> Duncan Booth <duncan.booth@i nvalid.invalid> spoke thus:
>[color=green]
>> If you make a reference to an object in another window, the object
>> will exist beyond the lifetime of the window so long as your
>> reference is still reachable from your code.[/color]
>
> Here's the test I performed - the Date object is intact before the
> window closes, but afterward it's mutated into something else...[/color]

That code works fine on Mozilla so I suspect the problem is IE specific.

My guess, given the amount of security I had to disable to get your example
to run on IE at all, is that Microsoft think there is a possible security
violation, so once the other window has been closed they don't let you
access the object. Any attempt to do things to the date object once the
window has been closed seems to throw an exception with name 'Error' and
message '0'. The object still exists, just useful things like getting its
value are being denied.

When I load your file from disc, it has security zone 'my computer', but
the popup has security zone 'internet'. I suspect this cross-zone scripting
is why strange things happen. If I give the script the 'mark of the web' so
it runs in internet zone, then it gets a security violation when it tries
to open the popup.

You can BTW get this specific example to work by copying the date:

function setDate( adate ) {
date=new Date(adate);
alert( date );
pwin.close();
}

[Duncan Booth]

Re: Scope of constructed objects

Duncan Booth wrote:
[color=blue]
> My guess, given the amount of security I had to disable to get your
> example to run on IE at all, is that Microsoft think there is a
> possible security violation, so once the other window has been closed
> they don't let you access the object. Any attempt to do things to the
> date object once the window has been closed seems to throw an
> exception with name 'Error' and message '0'. The object still exists,
> just useful things like getting its value are being denied.[/color]

Thinking a bit more about this:

You can only access an object from a different window if the window has the
same source (i.e. same server and port). That means that somewhere
internally the objects created by a window have to keep a reference to the
security context which created them. I guess that when you destroy the
window Microsoft must close the security context for that window and
thereby disable all subsequent access to objects created in that context.

[Christopher Benson-Manica]

Re: Scope of constructed objects

Duncan Booth <duncan.booth@i nvalid.invalid> spoke thus:
[color=blue]
> That code works fine on Mozilla so I suspect the problem is IE specific.[/color]

Perhaps, but in the "real" version of the code, where more or less the
same chain of events occurred, Firefox also threw an 'Error'/'0'
exception. IE's message was "The callee (server [not server
application]) is not available and disappeared; all connections are
invalid. The call did not execute.", which is quite cryptic. I have
no idea why my simple test did not produce the same behavior.
[color=blue]
> When I load your file from disc, it has security zone 'my computer', but
> the popup has security zone 'internet'. I suspect this cross-zone scripting
> is why strange things happen. If I give the script the 'mark of the web' so
> it runs in internet zone, then it gets a security violation when it tries
> to open the popup.[/color]

The original code was run from the internet and popped up a window
that was presumably in the same zone, although I wouldn't put it past
IE to do something bizarre anyway.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Lee]

Re: Scope of constructed objects

Christopher Benson-Manica said:[color=blue]
>
>Lee <REM0VElbspamtr ap@cox.net> spoke thus:
>[color=green]
>> No. It works as I expect, alerting the current date and time.
>> Local variables are destroyed once a function returns, but there
>> are no local variables in getADate(). The Date object survives
>> because there is still a reference to it. Once foo() returns,
>> the last reference to that Date object is destroyed and it will
>> be subject to garbage collection.[/color]
>
>So why, then, does a reference to a variable in another window become
>invalid when that window is destroyed?[/color]

Because the storage allocated for the object is freed when the
window containing it is destroyed.

[Dr John Stockton]

Re: Scope of constructed objects

JRS: In article <Xns95F7946426E 3Fduncanrcpcouk @127.0.0.1>, dated Tue, 8
Feb 2005 14:35:18, seen in news:comp.lang. javascript, Duncan Booth
<duncan.booth@i nvalid.invalid> posted :

AIUI, adate below is a Date Object.
[color=blue]
> date=new Date(adate);[/color]

AIUI, that calls for an implicit adate.toString( ) followed by parsing of
the string. In

date=new Date(+adate)

adate.toString( ) is not used, as + that gives NaN; evidently the +
persuades the Date Object that it really ought to be a number, its
..valueOf(); and the new Date() sees a number which it only needs to
memorise. It is therefore much faster (but that should be tested in all
browsers).

Also, with +, one always gets the right answer; but without, I get NaN
if the Object originally held a date in years -68 to +69.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Duncan Booth]

Re: Scope of constructed objects

Dr John Stockton wrote:
[color=blue]
> JRS: In article <Xns95F7946426E 3Fduncanrcpcouk @127.0.0.1>, dated Tue, 8
> Feb 2005 14:35:18, seen in news:comp.lang. javascript, Duncan Booth
><duncan.booth@ invalid.invalid > posted :
>
> AIUI, adate below is a Date Object.
>[color=green]
>> date=new Date(adate);[/color]
>
> AIUI, that calls for an implicit adate.toString( ) followed by parsing of
> the string.[/color]

You understand correctly.
[color=blue]
> In
>
> date=new Date(+adate)
>
> adate.toString( ) is not used, as + that gives NaN; evidently the +
> persuades the Date Object that it really ought to be a number, its
> .valueOf(); and the new Date() sees a number which it only needs to
> memorise. It is therefore much faster (but that should be tested in all
> browsers).
>
> Also, with +, one always gets the right answer; but without, I get NaN
> if the Object originally held a date in years -68 to +69.[/color]

Very interesting. I had assumed, without checking at all, that Date()
objects would copy themselves correctly. I see according to the Ecmascript
standard toString() and parse() are supposed (but not required) to
roundtrip, and the constructor has to work in exactly the same way as the
parse method, but as usual in javascript its the actual implementations
that matter, not the standard.

"It is intended that for any Date value d, the result of
Date.prototype. parse(d.toStrin g()) (15.9.4.2) is equal to d."

Thanks for that.