Problems with ASP.Net object and Javascript

[Richard Cornford]

RobG wrote:

if (f.nodeName.toLowerCase() == 'input')

The reason I prefer the regex is because f.nodeName may
not be typeof 'string', and if it isn't,
f.nodeName.toLowerCase() will fail. Of course this could
be avoided with:

if ('string' == typeof f.nodeName &&
f.nodeName.toLowerCase().indexOf('input') != -1)

but:

if (/input/i.test(f.nodeName))

is easier to read, probably faster (although speed isn't
the primary consideration in choosing this mechanism) and
guaranteed to produce the correct result regardless of the
typeof f.nodeName.

An alternative to safe execution with the comparison operation could
be:-

if((new String(f.nodeName)).toLowerCase() == 'input')

- and/or:-

if( (new String(f.nodeName)).toLowerCase().indexOf('input') != -1 )

- because the result of applying the ECMAScript internal ToString
function to null or undefined are known strings that do not resemble
'input'. The safety measure also has the advantage of not carrying an
overhead as the construction of the String object was implied by the
context of a String method call (assuming f.nodeName actually was a
string to start with).

Richard.

 

[Lasse Reichstein Nielsen]

An alternative to safe execution with the comparison operation could
be:-

if((new String(f.nodeName)).toLowerCase() == 'input')

While it's probably not hurtfull in any way, you never need to create
a new String object explicitly. Exactly the same effect would be
achieved by
if ((String(f.nodeName)).toLowerCase() == 'input')

Behind the scenes, there might be created a new String object anyway,
in order to call it's toLowerCase method, but an intelligent
Javascript interpreter should be able to optimize that away (should
such one exist).


I just don't like to see "new String(...)"
/L

 

[Richard Cornford]

An alternative to safe execution with the comparison
operation could be:-

if((new String(f.nodeName)).toLowerCase() == 'input')

While it's probably not hurtfull in any way, you never need
to create a new String object explicitly. Exactly the same
effect would be achieved by
if ((String(f.nodeName)).toLowerCase() == 'input')

Yes, the end result would be identical.

Behind the scenes, there might be created a new String
object anyway, in order to call it's toLowerCase method,

That is what ECMA 262 says happens when a method of a string object is
called on a string primitive.

but an intelligent Javascript interpreter
should be able to optimize that away (should
such one exist).

Yes, implementations may optimise any aspects of ECMA 262, they are only
required to behave (or appear to behave) as if they were following the
specification. But it is extremely difficult to tell which are
optimising what, and how. And in the cross-browser scripting world we
should not be too interested in optimisations that may only apply to
some implementations.

I just don't like to see "new String(...)"

And I don't mind seeing it when it is serving some purpose. Certainly
whenever I am planning to call more than three or so String methods on a
single string primitive I will usually explicitly convert it into a
String object (so that it is not necessary for the interpreter to do so
internally for each method call).

As a method of rendering a questionable, but probably string type,
property safe for the application of String methods I wouldn't argue
that passing the property's value through the String constructor called
as a function is equally effective. But as the language specification
says that an intermediate String object is created I see the explicit
construction of a String object as no more than rendering apparent what
should be expected to be happening anyway. (By 'expected' I mean that an
understanding based on the spec should expect that to be happening
conceptually, not that the interpreter actually has to be doing it.)

Maybe it is just a matter of personal bias, with my predominantly OO
programming experience numbing me to the sight of just another object
being constructed and your (I would guess) greater experience of
functional programming (certainly greater than mine) leaving you
preferring to see functions used. Or is there something more tangible
that can be said against the use of the object constructor?

You have probably guessed that I am not buying the efficiency due to
possible optimisation argument. And would counter by pointing out that
by the spec the implied String object creation will mean one extra call
to the internal ToString method with your version. Though as that call
is passing ToString a string primitive argument, which will just be
returned unaltered, the difference would be expected to be negligible.

Richard.

 

[Thomas 'PointedEars' Lahn]

synonyms

Joky: yes Seriously: no.

The DOM 2 spec says that it builds on the DOM 1 spec, so wouldn't it
supplement it rather then obsolete it?

Yo (Yes and no ;-)). See for yourself:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>
|
| Note: This specification renders the DOM Level 1 HTML Recommendation
| obsolete given that some changes from DOM Level 1 HTML are incompatible
| with that specification but represent more accurately the state of
| deployed software. W3C strongly suggests that developers and authors
| conform to DOM Level 2 HTML instead.


PointedEars

 

[David Dorward]

Joky: yes Seriously: no.

Then what is the difference? I was under the impression that ECMAScript was
just the standard that was created from JavaScript and that browsers
implemented the standard now.

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>

Ah, I was looking at the DOM 2 Core which didn't mention that.

 

[Thomas 'PointedEars' Lahn]

Then what is the difference? I was under the impression that
ECMAScript was just the standard that was created from JavaScript

(I had almost posted a lengthy detailed explanation but for some reason
it did not make it into the newsgroup. So now I write only this

Correct. You could call ECMAScript a subset of JavaScript since
not all JavaScript 1.1+ features made it into ECMAScript, e.g.
Getters and Setters.

and that browsers implemented the standard now.

They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript. They also implement and extend the W3C DOM,
a quasi-standard; the UA's DOM can also be accessed with ECMAScript
implementations (JavaScript in Gecko-based UAs, JScript in IE-based
ones) through the respective language binding feature.

I, among others, have already posted related information or pointers
thereto here several times. Google is your friend. [psf 6.1]


HTH

PointedEars

 

[Lasse Reichstein Nielsen]

David Dorward schrieb:

ECMAScript was created based on both Netscape JavaScript and Microsoft
JScript (which is probably why some of the features available in only
one of these is not in ECMAScript).

[ECMAScript]

They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript.

That's a yes. That these two browsers have named their extensions of
ECMAScript is mostly for historical reasons (they were named before
ECMAScript existed), but other browsers don't necessarily do so.

E.g., Opera implements ECMAScript v3. It doesn't implement Netscape
JavaScript nor Microsoft JScript. It has some extensions that are
compatible with parts of JavaScript and JScript, but it is not a full
implementation of either. As such, it's their own personal extension
of ECMAScript (and "an extended subset" of JavaScript and JScript).

Their own statement is:
<URL:http://www.opera.com/docs/specs/#ecmascript>.
Incidentally, the Windows version has a file called "es262-32.dll"

Did I have a point?
/L

 

[Thomas 'PointedEars' Lahn]

ECMAScript was created based on both Netscape JavaScript and Microsoft
JScript (which is probably why some of the features available in only
one of these is not in ECMAScript).

Having reviewed ECMA-262 (First Edition), I have to admit that my sources
were apparently incorrect. You're right, it states on page 5:

| This ECMA Standard is based on several originating technologies, the most
| well known being JavaScript? (Netscape Communications) and JScript?
| (Microsoft Corporation). The development of this Standard has started in
| November 1996.

[ECMAScript]

They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript.

That's a yes.

If I meant "yes", I would have said so.

That these two browsers have named their extensions of ECMAScript is
mostly for historical reasons (they were named before ECMAScript existed),

Those extensions are mostly not compliant with ECMAScript.

but other browsers don't necessarily do so.
E.g., Opera implements ECMAScript v3.

No. It implements many features of ECMAScript editions (_not_ versions,
BTW).

It doesn't implement Netscape JavaScript nor Microsoft JScript. It has
some extensions that are compatible with parts of JavaScript and JScript,

Which is why it does not implement ECMAScript 3 (per specification).

but it is not a full implementation of either.

Yes, indeed.

As such, it's their own personal extension of ECMAScript (and "an extended
subset" of JavaScript and JScript).

There is only one ECMAScript (with currently 4 possible editions). Any
extension/omission of it that is not allowed by the specification does
not result in an (compliant) ECMAScript implementation, strictly speaking.
And certainly the languages are not the same and/or cannot be used as
synonyms which was the question here.

Their own statement is:
<URL:http://www.opera.com/docs/specs/#ecmascript>.
Incidentally, the Windows version has a file called "es262-32.dll"

Did I have a point?

You missed it somehow.


PointedEars

 

[Lasse Reichstein Nielsen]

Those extensions are mostly not compliant with ECMAScript.

Depending on how one views extensions to a standard vs. compliance
with it. If all requirements of the standard are complied with, the
existence of further features would not make the extended language
uncompliant ... unless "no further features" *is* a requirement
of the standard. I don't believe it is for ECMAScript, quite the
contrary, in fact.

There is a difference between extending the syntax of the language
(which only IE does, with its conditional compilation features) and
extending the runtime environment that, syntactically correct,
programs are run in. The runtime environment is specified by the
standard, but not exclusively. The standard allows for extensions.
It even expects them.

Which is why it does not implement ECMAScript 3 (per specification).

ECMA262, 3rd edition (thanks), states (section 4):
---
ECMAScript as defined here is not intended to be computationally
self-sufficient; indeed, there are no provisions in this
specification for input of external data or output of computed
results. Instead, it is expected that the computational environment
of an ECMAScript program will provide not only the objects and other
facilities described in this specification but also certain
environment-specific host objects, whose description and behaviour
are beyond the scope of this specification except to indicate that
they may provide certain properties that can be accessed and certain
functions that can be called from an ECMAScript program.
---

A later note, from section 15, is:
---
NOTE Implementations that add additional capabilities to the set of
built-in functions are encouraged to do so by adding new functions
rather than adding new parameters to existing functions.
---

The ECMAScript standard writers *expect* implementations to have an
environment that extends that specified by the standard, while still
being compatible.

There is only one ECMAScript (with currently 4 possible editions).

Yes. It is a specification (or four).

There are several implementations of languages that comply with this
specification. Each is used in an environment where the standard-
specified runtime environment is extended with host objects and
non-standard properties.

Any extension/omission of it that is not allowed by the
specification does not result in an (compliant) ECMAScript
implementation, strictly speaking.

I disagree with this. Compliance is possible while also including
extensions, because the standard is not written to exclude extensions.

And certainly the languages are not the same and/or cannot be used
as synonyms which was the question here.

That is correct. There is no language called "Javascript" (lower case
"s").

Should anyone dare to use the word anyway, we'll just have to find a
meaning for it. I suggest "a generalization over ECMA-262-compliant
scripting languages".

/L

 

[Richard Cornford]

Lasse Reichstein Nielsen wrote:

Those extensions are mostly not compliant with ECMAScript.


No. It implements many features of ECMAScript editions
(_not_ versions, BTW).


Which is why it does not implement ECMAScript 3 (per
specification).


Yes, indeed.


There is only one ECMAScript (with currently 4 possible
editions). Any extension/omission of it that is not allowed
by the specification does not result in an (compliant)
ECMAScript implementation, strictly speaking. And certainly
the languages are not the same and/or cannot be used as
synonyms which was the question here.

<snip>

ECMA 262 3rd edition commences with a section on conformance. Which
says:-

<quote cite=""ECMA 262 3rd edition Section 2>
2 Conformance

A conforming implementation of ECMAScript must provide and support all
the types, values, objects, properties, functions, and program syntax
and semantics described in this specification.

....

A conforming implementation of ECMAScript is permitted to provide
additional types, values, objects, properties, and functions beyond
those described in this specification. In particular, a conforming
implementation of ECMAScript is permitted to provide properties not
described in this specification, and values for those properties, for
objects that are described in this specification.

A conforming implementation of ECMAScript is permitted to support
program and regular expression syntax not described in this
specification. In particular, a conforming implementation of ECMAScript
is permitted to support program syntax that makes use of the "future
reserved words" listed in section 7.5.3 of this specification.
</quote>

Making it very clear that ECMA 262 provides for extension that would
include all of the differences between JavaScript, JScript and Opera's
implementation and an implementation that included nothing but what is
required by the standard. Thus they are all conforming ECMAScript
implementations.

Richard.

 

[Thomas 'PointedEars' Lahn]

Depending on how one views extensions to a standard vs. compliance
with it.

There is nothing that allows for private meaning here. A specification
is a specification. Non-compliant behavior is just that.

If all requirements of the standard are complied with, the
existence of further features would not make the extended language
uncompliant ... unless "no further features" *is* a requirement
of the standard. I don't believe it is for ECMAScript, quite the
contrary, in fact.

There is a difference between extending the syntax of the language
(which only IE does, with its conditional compilation features) and
extending the runtime environment that, syntactically correct,
programs are run in. The runtime environment is specified by the
standard, but not exclusively. The standard allows for extensions.
It even expects them.

It allows for certain specified extensions, not extensions in general.
Conditional comments are one of the features that is not compliant to
ECMAScript. An ECMAScript compliant compiler would yield a syntax
error then.

Which is why it does not implement ECMAScript 3 (per specification).

ECMA262, 3rd edition (thanks), states (section 4): [...]

Don't play human gateway this way. You can assume I have not only
downloaded but also read and understood all of it.

[...] it is expected that the computational environment
of an ECMAScript program will provide not only the objects and other
facilities described in this specification but also certain
environment-specific host objects, [...]

That does not say *any* extension to the *language* is allowed without
making it non-compliant. Host objects are a completely different issue.

A later note, from section 15, is:

Your point is?

The ECMAScript standard writers *expect* implementations to have an
environment that extends that specified by the standard, while still
being compatible.

They expect extensions described by the specification and they expect
the existence of host objects. They do not expect that an implementation
calling itself ECMAScript compliant is in fact non-compliant.

I disagree with this. Compliance is possible while also including
extensions, because the standard is not written to exclude extensions.

You disagree with the specification itself. What is not explicitely
"allowed" in a *specification* is "forbidden" in terms of compliance
with it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[...]
<quote cite=""ECMA 262 3rd edition Section 2>
2 Conformance
[...]
</quote>

Making it very clear that ECMA 262 provides for extension that would
include all of the differences between JavaScript, JScript and Opera's
implementation and an implementation that included nothing but what is
required by the standard. Thus they are all conforming ECMAScript
implementations.

Point taken. Thank you.


PointedEars

 

[Jim Ley]

Thus they are all conforming ECMAScript
implementations.

Well there are bugs...

Jim.

 

[Thomas 'PointedEars' Lahn]

Well there are bugs...

Please be more specific.


PointedEars

 

[Jim Ley]

Please be more specific.

There exist bugs in the JavaScript and JScript implementations that
make them non-compliant.

Jim.

 

[Ivan Marsh]

[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.

Well there are bugs...

Please be more specific.

There exist bugs in the JavaScript and JScript implementations that
make them non-compliant.

Being non-compliant isn't a bug.

 

[Lasse Reichstein Nielsen]

Being non-compliant isn't a bug.

But claiming to be compliant and not being it, suggests that the
noncompliance is due to a bug, not a deliberate choice.

It should be noticed that JScript is not claimed to be compliant:
<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsconabout.asp>

Rhino and SpiderMonkey do claim compliance:
<URL:http://www.mozilla.org/js/>

/L

 

[Thomas 'PointedEars' Lahn]

[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.
Well there are bugs...

Please be more specific. <------------------------------------------.

|
There exist bugs in the JavaScript and JScript implementations that |
make them non-compliant. |

|
----------------------------------------------------------------------'


PointedEars

 

[Richard Cornford]

Well there are bugs...

Fair enough, they all have minor behaviour that does not strictly
conform with the what is specified in ECMA 262. But it is not the
extensions that are getting in the way of that.

Ricahrd.

 

[Lasse Reichstein Nielsen]

Jim Ley wrote:
[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.
Well there are bugs...
Please be more specific. <------------------------------------------.

|
There exist bugs in the JavaScript and JScript implementations that |
make them non-compliant. |

|
----------------------------------------------------------------------'

Take arrays, a quite fundamental part of the language:

In IE:
[1,2,3,].length
is 4, it should be 3.

In FireFox:
"1" in [0,,2]
is true, should be false.

/L