Little Help with JavaScript

[VK]

It remains pretty hard to believe that anyone is fool enough to employ
you to write computer software.

For the sake of fairness I need to note that over all these years I
didn't see yet a single finished program from you (commented code
snippets and test samples discounted). The only functional application
with a pronounced objective I know is your "Table Body Scroller" made
back in 2004:
http://web.archive.org/web/20040803....demon.co.uk/example_scripts/tableScroll.html
I am not stating that you cannot write programs. Most probably any
program you would write would become a new word in the programming and
a new stage in the programming theory. I am not denying anything of
that, but simply criticizing someone's else products without showing
anything of your own tends to be on the hypocrisy side.

The amount of time you must waste as a
result of taking the things in your head seriously is unimaginable.

As you wish. Assuming the world is full of fulls and I am hugely
capitalizing on it. It is not true but as you wish.

And thank you again for your great hint about stay alone blocks, even
if you are unable to see why so great and how so great it was.

 

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

In Usenet, that line belongs on the top of all the quotations, in order to
make it easy to quote that later. You have been told before numerous times.

Now you are definitely kidding.

No, he is not.

{"key1":"value1"}
structure is a valid JSON object data but it is not JavaScript syntax
compatible for the above spelled reasons and leads to "invalid label"
syntax error.

Only if used in a context where `{'...`}' are parsed as delimiters of a
/Block/ statement and consequently `"key": "value"' as a
/LabelledStatement/, e.g.:

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /Block/
→ { /StatementList/ }
→ { /Statement/ }
→ { /LabelledStatement/ }
→ { /Identifier/ : /Statement/ }
[ES3F, 12.1]

Richard explained that to you in greater detail; but obviously, and
unsurprisingly, you have not been paying attention.

By creating the assignment context like
var obj = {"key1":"value1"}
we are masking this potential error

No, in that context it is parsed, as Richard already explained to you, as a
perfectly valid /AssignmentExpression/:

/Statement/
→ /VariableStatement/
→ var /VariableDeclarationList/ ;
→ var /VariableDeclaration/ ;
→ var /Identifier/ /Initialiser/ ;
→ var /Identifier/ = /AssignmentExpression/ ;
→ ...
→ var /Identifier/ = /ObjectLiteral/ ;
[ES3F, 11.3.1]

and successfully instantiating obj over assignment.

Whatever that is supposed to mean.

If - as many others - we are using JavaScript allowed
shortcut without quotes around the key name then we also masking this
ticking bomb:
{"key1":"value1"}

You don't know what you are talking about.

And
var obj = eval( '{key1:"value1"}' );
window.alert(typeof obj); // string
?

Since the string value of eval() is (to be) parsed as a /Program/, what
looks like an /ObjectLiteral/ at first is in fact parsed as a /Block/
statement:

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /Block/
→ { /StatementList/ }
→ { /Statement/ }
→ { /LabelledStatement/ }
→ { /Identifier/ : /Statement/ }
→ { /Identifier/ : /ExpressionStatement/ }
→ { /Identifier/ : /Expression/ }
→ { /Identifier/ : /AssignmentExpression/ }
→ ...
→ { /Identifier/ : /Literal/ }
→ { /Identifier/ : /StringLiteral/ }

And the result of a /Program/ is the result of the evaluation of its
/SourceElements/. [ES3F, 15.1.2.1, 14 pp.]

A simple workaround is to put the supposed-to-be Object initializer in
parentheses -- eval('({key1:"value1"})'); -- which causes it to be parsed as
follows:

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /ExpressionStatement/
→ /Expression/
→ ( /Expression/ )
→ ...
→ ( /ObjectLiteral/ )

A less simple and more expensive workaround -- but I have seen it before --
is using brackets:

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /ExpressionStatement/
→ /Expression/
→ ...
→ /ArrayLiteral/
→ [ /ElementList/ ]
→ [ /AssignmentExpression/ ]
→ ...
→ [ /ObjectLiteral/ ]

And
var obj = eval( '{"key1":"value1"}' );
// syntax error "invalid label"
?

Since the string value of eval() is parsed as a /Program/, what looks like
an /ObjectLiteral/ at first is in fact parsed as a /Block/ statement, and
`"key1"' does not satisfy the criteria for a label since it needs to be an
/Identifier/:

/Program/
→ /SourceElements/
→ /SourceElement/
→ /Statement/
→ /Block/
→ { /StatementList/ }
→ { /Statement/ }
→ { /LabelledStatement/ }
→ { /Identifier/ : /Statement/ }
(→ Syntax error)
[ES3F, 15.1.2.1 pp.]

And
var obj = eval('{"key1":"value1", "key2" : "value2"}');
// syntax error "invalid label"
?

(Granted, this one is a bit tricky.)

The comma is not parsed as delimiter between name-value pairs in an Object
initializer, but as a comma operator here. `"key1":"value"' must be parsed
as a /LabelledStatement/, and `"key1"' does not satisfy the criteria for a
label since it needs to be an /Identifier/:

/Program/
→ /SourceElement/
→ /Statement/
→ /Block/
→ { /StatementList/ }
→ { /StatementList/ /Statement/ }
→ { /Statement/ /Statement/ }
→ { /LabelledStatement/ /LabelledStatement/ }
→ { /Identifier/ : /Statement/ /LabelledStatement/ }
→ { /Identifier/ : /ExpressionStatement/ /LabelledStatement/ }
→ { /Identifier/ : /Expression/ /LabelledStatement/ }
→ { /Identifier/ : /Expression/ , /AssignmentExpression/
/LabelledStatement/ }
(→ Syntax error)
[ES3F, 15.1.2.1, ..., 11.14]

If the productions following `/LabelledStatement/ /LabelledStatement/' are
correct (the productions until that undoubtedly are), then the second syntax
error, at the second /LabelledStatement/, is ignored.

And so on? I did over last hours more than planned for the week -

If you only tried to understand how the parser and grammar works, if you
only read the relevant parts of the Specification once, you would
understand; but then again, given your record of making up stories to fit
your arguments instead, probably not even then.


PointedEars

 

[Thomas 'PointedEars' Lahn]

But the - eval - function evaluates its string arguments as javascript
Programs, and the two structures that can make up a Program as
Statements and FunctionDeclarations.

JFTR: This wording is misleading. Per current Specification, eval() takes
only one argument (ES3F, 15.1.2.1). If that argument is a string value, the
return value of eval() is the result of the /Program/ that the string is
parsed as (potential syntax errors aside); if it is not a string value, the
return value of eval() is the argument itself (which makes `eval(42 + 23)'
and the like pointless calls).


PointedEars

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 19 okt 2009 in comp.lang.javascript:

JFTR: This wording is misleading. Per current Specification, eval()
takes only one argument (ES3F, 15.1.2.1). If that argument is a
string value, the return value of eval() is the result of the
/Program/ that the string is parsed as (potential syntax errors
aside); if it is not a string value, the return value of eval() is the
argument itself

Which is a difficult way of saying about the argument of eval():

1 if it is a string the string is executed and the result is returned.

2 if it is not a string the content is executed as if it were a string
and the result is returned.

so:

var abc = 3;
var r1 = eval(abc == 3); // true
var r2 = eval('abc == 3'); // true
var r3 = eval(abc); // 3
var r4 = eval('abc'); // 3ny

(which makes `eval(42 + 23)' and the like pointless calls).

Not more so than a literal string eval like eval('42 + 23');
and a litteral string could be dynamic in serverside code sense:

<% 'serverside JS assumed under ASP
var x;
if (b) x = 'new Date();'
else x = 17;
%>

var r5 = eval('<% = x %>'); // returns the local date or 17

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 18 Oct 2009 15:08:15, John G Harris
<[email protected]> posted:


But I was writing about valid JavaScript, not JavaScript with a syntax
error.

<snip>

I don't know what "every" means in Physics, but in Mathematics and
Computer Science it means every, all, without as many as one exception.

You say that by inserting semicolons you can make every statement end
with a semicolon. I have demonstrated that there is a case where by
adding a semicolon at the end of a statement you get a syntax error.
Therefore it is not true that "every statement will be terminated by a
semicolon."

The mess would be avoided if your paragraph started with something like
"Each statement ends with either a semicolon, a close curly bracket, or
a nested, smaller, statement."

Then you can say what you want about semicolon-terminated statements
without causing VK-like confusion.

John

PS Students who demanded to be told the answer made me very irritable.

 

[Branco]

vaib wrote:

I am relatively new to JavaScript and I have to develop something that
seems like a good amount o learning curve for me right now.

To make it simple here's the most simplistic view of what I have to do
- A page where two DIVs are placed side by side and there's a button
below. On the click of the button the DIVs should exchange their
positions ( ofcourse, with everything in them also being exchanged ).
I have to make it resolution free.

I do not need any code as such ( although any help is appreciated )
but what approach to take would be a great help.

<snip>

If all you want is to exchange their positions, then I'd suggest you
make the positioning a css rule and simply apply the correct style to
each div.

<!--Start Air Code -->
<style>
.left-box {float:left;}
.right-box {float:right}
#A { /*...*/ }
#B { /*...*/ }
</style>
<script>
function ReplaceClass(E, OldClass, NewClass){
//replaces OldClass for NewClass in E.className.
//returns true if successfull, false otherwise
//...
}

function Swap(A, B) {
A = document.getElementById(A);
B = document.getElementById(B);

if (ReplaceClass(A, 'left-box', 'right-box')) {
ReplaceClass(B, 'right-box', 'left-box');
} else {
ReplaceClass(B, 'left-box', 'right-box');
ReplaceClass(A, 'right-box', 'left-box');
}
} //function Swap(...)
</script>
<div id='A' class='left-box'><div>Text in A</div></div>
<div id='B' class='right-box'><div>Text in B</div></div>
<input type='button' value = 'Swap' onclick='Swap()'/>
<!--End Air Code -->

Otherwise, if you want to actually exchange the content of each div,
then notice that styles based on parentship will be affected. Also,
sh*te may ensue if you try to swap two elements where one is contained
in the other.

<!--Start Air Code -->
<style>
#A div {font-weight:bold;font-size:14px;}
#B div {font-size:32px;color:red}
</style>
<script>
function Swap(A, B) {
//swaps the content of two elements
A = document.getElementById(A);
B = document.getElementById(B);
var Temp = document.createElement("div");
var c = A.childNodes;
while(c.length > 0) Temp.appendChild(c[0]);
c = B.childNodes;
while(c.length > 0) A.appendChild(c[0]);
c = Temp.childNodes;
while(c.length > 0) B.appendChild(c[0]);
Temp = null;
}
</script>
<div id='A' class='left-box'><div>Text in A</div></div>
<div id='B' class='right-box'><div>Text in B</div></div>
<input type='button' value = 'Swap' onclick='Swap()'/>
<!--End Air Code -->

HTH.

Regards,

Branco.

 

[Thomas 'PointedEars' Lahn]

It just occurred to me that one could also use a comma operator instead
of so-common grouping one:

var json = '{ "x": 1 }';
eval('1,' + json);

which would actually result in concatenation of only 2 strings instead
of 3, and be arguably cleaner (at least 3 characters shorter) -

var json = '{ "x": 1 }';
eval('(' + json + ')');

However, grouping operator is probably more efficient here, since it
merely evaluates an expression (avoiding even GetValue), whereas comma
operator would result in evaluation of first expression, followed by
calling GetValue on it, and so on with the second one.

This is all just a minor quibble, of course.

ACK. However, I would appreciate it if you quoted me so that the meaning of
my replies cannot be misinterpreted. Your current quoting suggests that VK
would have been right, and that I proposed a workaround for a perceived
incompatibility problem, which I definitely did _not_.


PointedEars

 

[wilq]

It isn't.

What a constructive criticism.

 

[Thomas 'PointedEars' Lahn]

What a constructive criticism.

As is yours, isn't it?

I won't start the whole discussion again just because you are too lazy for a
bit of research. There are enough examples available in the newsgroup's
archives where w3schools.com is so utterly wrong that its misinformation is
the cause of the problem, to discount it as a viable development resource.

You would have know that had you read my posting whole.


PointedEars

 

[vaib]

Sorry about that. Apparently, I didn't pay enough attention when quoting.

Thanks all you. I got the solution ( and understood it too ).
I'll post one more problem I am facing - it's a code that I wrote. It
needs some advise.

Thanks to all.


- Vaibhav