«

Richard Cornford has wrote great part of what i expected.

PS to avoid errors in statemtens like alert(cool) we could use
alert(this.cool); /* and thus really using [[Get]] method of JavaScript
which returns undefined if cool is not in scope */

Best regards.
Luke.

Richard Cornford wrote:

> So, if you specify LANGUAGE="JavaScript1.2" you may get two different
> sorts of language behaviour from the interpreter depending on which
> browser is used. This is a _bad_thing_.

Note <https://bugzilla.mozilla.org/show_bug.cgi?id=255895>, with Firefox
1.5 (already in the betas and release candidates) Mozilla has dropped
the change that <script language="JavaScript1.2"> used to trigger for
script evaluation.
Of course one more reason not to use <script language="JavaScript1.2">
in HTML documents these days.

--

Martin Honnen
http://JavaScript.FAQTs.com/

In article < .com>, VK
<> writes

<snip>
>This situation was fully satisfying for everyone except some bored
>academical minds. These minds did not like the fact that there is
>something that has a string representation ("undefined") but is not
>represented per se.
>
>Thus they have introduced *undefined* value. The consequence they did
>not think about was that this value will be able by default participate
>in the comparison operations *and* in the assignment operations. This
>created the following definitely buggy situation:
<snip>

No. In old browsers, ECMA 262 v2, the complicated rules for == meant you
couldn't tell the difference between null and undefined (never assigned
to).

Newer browsers, as recorded in ECMA 262 v3, have === which does allow
you to tell the difference. If x has never been assigned to it must now
have something it is === to, and it can't be null so they invented a new
keyword, undefined, to be that something.

John
--
John Harris

Richard Cornford said the following on 11/20/2005 9:19 AM:
> Randy Webb wrote:
> <snip>
>
>>Thomas is a decent Theorist. If you want to learn a lot of
>>theory then read Richard Cornford. He is the best Theorist
>>around here.
>
>
> You don't think that Lasse Reichstein Nielsen has a better claim on that
> title (for his ability to place the theory in a wider context than I
> can)?

Never really thought about that one. I do know that when it comes to the
specs, I have never seen him be wrong about what they say.

::Off to ponder Lasse being a Theorist::
<g>
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Lasse Reichstein Nielsen said the following on 11/20/2005 7:44 AM:
> Randy Webb <> writes:
>
>
>>No browser will ever be 100% ECMA Compliant. When I say 100% I mean
>>that it follows everything in ECMA, implements it according to ECMA,
>>and nothing more.
>
>
> Well, that would be a different interpretation of "ECMA 262 compliant"
> than it uses itself. ECMAScript is meant to be extended, both at the
> runtime environment level with host objects, and with extended syntax
> and semantics. Being compliant means following everthing in the standard,
> but there is no requirement of "nothing more".

Fair enough.

> That said, I doubt there will ever be a 100% compliant implementation
> anyway. There will probably always be some obscure corner case that
> is implemented slightly incorrectly when used on the first Thursday
> of a month. "The number of bugs in a program is constant over time."

Indeed

>
>>It will never happen. So, even if you know ECMA 100%, it still won't
>>be enough because you will still have to know how the browsers deal
>>with it. May as well learn the browser behavior and you are set.
>
>
> Indeed. Still, the major problem with scripting browsers is not the
> Javascript language, browsers are very close to ECMAScript compliance.
> It is the browser DOM, which differs widely.

100% Agreed.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

"matty" <> writes:

> The original question was if those constructs were legit. Is it a
> "standard" to use the "Javascript1.2" construct or not.

It is "standard" in the sense that it *can* be used in a validating
HTML 4.01 Transitional document.
The behavior is *not* standardized, but left up to the clients that
uses it.
It was never recommended by the W3C. The "language" attribute was
deprecated already in the first version of HTML that included it.
It was only included for compatability with existing browsers and
pages.

The use of "JavaScript1.2" as the version is possibly the worst value
of the language attribute that one can use, since it specifies a
version of Javascript that differs from other versions on the *same*
syntax. If it matters for your page, then the page *will* break in
the browsers that only support one version of Javascript.

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

Luke Matuszewski wrote:

> Richard Cornford has wrote great part of what i expected.

What are you referring to?
<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>

> PS to avoid errors in statemtens like alert(cool) we could use
> alert(this.cool); /* and thus really using [[Get]] method of
> JavaScript which returns undefined if cool is not in scope */

True. However, `this.cool' is not always the same as `cool':

var cool = 42;

function Foo()
{
alert([this.cool, cool])
}

Foo.prototype = {
Foo: Foo,
cool: 1337
};

Foo(); // 42,42
var foo = new Foo(); // 1337,42
foo.Foo(); // 1337,42


PointedEars

JRS: In article < .com>
, dated Sun, 20 Nov 2005 08:30:00, seen in news:comp.lang.javascript,
Luke Matuszewski <> posted :

>( * so there is no programmical way to test if variable was defined but
>not assigned a value explicitly... but i assume there is no need to )

var U // DO NOT ASSIGN TO U
var X
var Z1 = X==U
X = "something"
var Z2 = X==U
X = U
var Z3 = X==U
alert([Z1, Z2, Z3])

gives true,false,true so that one can very nearly tell.

Consider

function Inc(Parameter, maybeAnother) { var R, U
R = Parameter
if (maybeAnother != U) R += maybeAnother
return R }

(modelled on something in another language) which indicates a possible
use of testing for undefined.

The introduction of undefined as a keyword meaning undefined was a
great mistake, no doubt originated by a person with inadequate
experience of linguistics -- it makes discussion of the subject
unnecessarily difficult. Something like undef would have been
better, or unbestimmt or something neologistic such as wotzat .

There's something for saying that a language should not have reserved
words; instead, it should have reserved not-words - for example,
funkshun rather than function .

Implementations of Algol often used one of [ ' " ] as string quote and
the other as reserved word quote; and I recall one where "begin" was
written !begin but could be written as !beg. instead - any
special word could be so abbreviated to the minimum needed to be
differentiated from others. It made various forms of processing,
including discussion, easier. part of the software would expand any
such abbreviations.

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

"Luke Matuszewski" <> writes:

> ( * so there is no programmical way to test if variable was defined but
> not assigned a value explicitly... but i assume there is no need to )

There shouldn't be a way, because there is no difference between a
declared variable that has not been assigned to, and one that has been
assigned the undefined value.

When you declare a variable, you create a property on the variable
object (the global object if in global scope). Quoting section 12.2
of ECMA262 3rd ed.:
"Variables are initialised to undefined when created."


(Curiosity: variable properties are created with the property attribute
DontDelete, except when inside eval scope. The following alerts the
result "number, undefined":
(function() {
var x = 42;
eval("var y = 37;");
delete x;
delete y;
alert([typeof x, typeof y]);
})()
The wonders of reading ECMA262 ...

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