HOLY ROBIN, BATMAN!

[L8V2L]

To POST data like an HTML form, add an HTTP header with setRequestHeader(). Specify the data you want to send in the send() method:

xmlhttp.open("POST","ajax_test.asp",true);xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");xmlhttp.send("fname=Henry&lname=Ford");

SO what is it doing? What is it sending? Edited June 22, 2014 by L8V2L

[L8V2L]

x = ~-y; w = x = y = z; q = a?b:c?d:e?f:g; are equivalent to: x = ~(-y); w = (x = (y = z)); q = a?b:(c?d:(e?f:g)); because the unary, assignment, and ternary conditional operators have right-to-left associativity.I can't seem to see how it's rl when you evaluate the condition first, then a value is return depending on that condition.Unless the value are evaluated first then the condition, but if so ghat mean the interpreter will have to carry a stack with it of the value it evaluated when it evaluated the condition and assign the value. I can see if it evaluate the condition then retrieve the value and finally going to the left from the right that it assign it to the variable/property. If that's the case, it more so going left to right to left, instead of right to left.

[justsomeguy]

What is it sending?

The data in the send method. There are 2 variables with values.

[L8V2L]

xmlhttp.open("POST","ajax_test.asp",true);xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");/* <~~~I'm referring to this line, sorry for not being clearer. (Is it posting the information in that file on the server(This is a non-knowledgeable guess))*/xmlhttp.send("fname=Henry&lname=Ford");

Edited June 23, 2014 by L8V2L

[thescientist]

It's setting a header for the request.

http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

[L8V2L]

Var num = 0;((num === 1)&& --num)||((num === 0) && ++num);

To my knowledge, it should toggle... Do I really need to explame the code here? It's comparasion, Boolean, side effects.

[justsomeguy]

If I ever saw code like that I would remove it immediately. Good code is simple code. How about this:

var toggle = false;toggle = !toggle;

A little easier to understand, right?Even this is easier to understand, but still needlessly complex:

var toggle = 0;toggle = (toggle === 0 ? 1 : 0);

Again, good code is simple code. The best programmers write code that is very easy to understand.

[L8V2L]

If I ever saw code like that I would remove it immediately. Good code is simple code. Good code is simple code. The best programmers write code that is very easy to understand.

This is easy to understand...

var num = 0;((num === 1)&& --num)||((num === 0) && ++num);//break down:/*var num = 0;((num === 1)&& --num)//side effect if true||//if not true((num === 0) && ++num);//side effectThis is for experimental proposal, and educational. To gain understanding.var num = 0;((num === 1)&& --num)||((num === 0) && ++num);It'll toggle to one, but not to 0, only when separated.Again! Please, if you can see why from sight alone, why does it not toggle?*/

Edited June 24, 2014 by L8V2L

[L8V2L]

I discover why with the solution. If you care to know, read the code.

void((eval((num === 0)&&(num = 1)))||(eval((num === 1)&&(num = 0))));console.log(num);/*//var num = 0;((num === 0)&&(num = 1))||((num === 1)&&(num = 0));//var num = 0;(eval((num === 0)&&(num = 1)))||(eval((num === 1)&&(num = 0)));//var num = 0;(eval((num === 1)&&(num = 0)))||(eval((num === 0)&&(num = 1)));*/

[thescientist]

nothing about that is pleasant to read. I see you missed the point of the lesson about keeping code simple.

[justsomeguy]

It doesn't toggle because when num is 1, it runs both expressions. If you don't know why, that's because the code is confusing. That's why you shouldn't write confusing code. It doesn't help when you're trying to use tricks or be cute and you end up creating something that is too complex to understand at a glance. You should be able to read code as fast as you read a book, not have to sit there and stare at a line to figure out what the ###### it's doing.

[justsomeguy]

If you want another example, consider Duff's device from C. Which of these is easier to understand:

do {                          /* count > 0 assumed */    *to = *from++;            /* Note that the 'to' pointer is NOT incremented */} while(--count > 0);

	register n = (count + 7) / 8;	switch(count % 8) {	case 0:	do {	*to = *from++;	case 7:		*to = *from++;	case 6:		*to = *from++;	case 5:		*to = *from++;	case 4:		*to = *from++;	case 3:		*to = *from++;	case 2:		*to = *from++;	case 1:		*to = *from++;		} while(--n > 0);	}

Duff's device might be faster, but I bet you can't tell me what it does, and if you were asked to debug it I bet you would have problems.

[L8V2L]

nothing about that is pleasant to read. I see you missed the point of the lesson about keeping code simple.

And I see you didn't read my post about experimenting, getting to understand how the simple feature work, cause there is more to these minor feature then what w3s lead on. W3s is a great place to get your feat wet, but that's all you doing for most of the tutorials. You have to jump in the pages of overwhelm if you want to submerge in what you are learning. (But I don't feel quite worthy of changing my signature to reflect this yet.

[L8V2L]

It doesn't toggle because when num is 1, it runs both expressions. If you don't know why, that's because the code is confusing. That's why you shouldn't write confusing code. It doesn't help when you're trying to use tricks or be cute and you end up creating something that is too complex to understand at a glance. You should be able to read code as fast as you read a book, not have to sit there and stare at a line to figure out what the ###### it's doing.

Could you clarified? Why when switch, 0 doesn't cause that? Does it being a falsy value have something to do with it? As I pounder out how to make it work, I still don't understand why it didn't work to a full exstant. I just figure it was the order of how it was arrange that made it fail. But since you seem to know, could you give more feedback.

void((eval((num === 0)&&(num = 1)))||(eval((num === 1)&&(num = 0))));console.log(num);/*//var num = 0;((num === 0)&&(num = 1))||((num === 1)&&(num = 0));//var num = 0;(eval((num === 0)&&(num = 1)))||(eval((num === 1)&&(num = 0)));//var num = 0;(eval((num === 1)&&(num = 0)))||(eval((num === 0)&&(num = 1)));*/

Edited June 24, 2014 by L8V2L

[L8V2L]

If you want another example, consider Duff's device from C. Which of these is easier to understand:

do {                          /* count > 0 assumed */    *to = *from++;            /* Note that the 'to' pointer is NOT incremented */} while(--count > 0);

	register n = (count + 7) / 8;	switch(count % 8) {	case 0:	do {	*to = *from++;	case 7:		*to = *from++;	case 6:		*to = *from++;	case 5:		*to = *from++;	case 4:		*to = *from++;	case 3:		*to = *from++;	case 2:		*to = *from++;	case 1:		*to = *from++;		} while(--n > 0);	}

Duff's device might be faster, but I bet you can't tell me what it does, and if you were asked to debug it I bet you would have problems.

I would know, but I guess increment from++ store it in to. Then for the second code increment from store it in to as the module return 0 do it 8 times over, 1 do it one times over, 2 to it two times, etc. but I'm not a c programmer. I don't see hoe this have anything to do to any question I have ever ask.

[justsomeguy]

This:

((num === 0)&&(num = 1))||((num === 1)&&(num = 0));

is different than this:

((num === 1)&& --num)||((num === 0) && ++num);

The first one will generally work, but is still needlessly complex (and inefficient) and I would still replace it with a boolean toggle. The second one will not toggle the value, it will keep the value at 1.

I don't see hoe this have anything to do to any question I have ever ask.

That's unfortunate, because this is computer science. Programming is not about memorizing syntax of a particular language, it's about knowing the theory. I wasn't asking you to explain what those do, I want you to look at them and figure out which one is easier to understand. They do the same thing in a particular situation. The point I am trying to make is that code is better when it is simple. Duff's device is an unrolled loop that implements a serial copy to a register, but the interlacing of the switch statement with the do loop is confusing enough to make it a red flag for possible bugs. The code is too complex for most programmers to know if it works right just by reading it. That's the point. You post complex examples that would never be used in practice because they are needlessly complex when something much simpler would do the same job. If you can't figure out why that code example does not toggle the number, then that's a perfect example of something that is needlessly complex.

[L8V2L]

This:

((num === 0)&&(num = 1))||((num === 1)&&(num = 0));

is different than this:

((num === 1)&& --num)||((num === 0) && ++num);

The first one will generally work, but is still needlessly complex (and inefficient) and I would still replace it with a boolean toggle. The second one will not toggle the value, it will keep the value at 1. That's unfortunate, because this is computer science. Programming is not about memorizing syntax of a particular language, it's about knowing the theory. I wasn't asking you to explain what those do, I want you to look at them and figure out which one is easier to understand. They do the same thing in a particular situation. The point I am trying to make is that code is better when it is simple. Duff's device is an unrolled loop that implements a serial copy to a register, but the interlacing of the switch statement with the do loop is confusing enough to make it a red flag for possible bugs. The code is too complex for most programmers to know if it works right just by reading it. That's the point. You post complex examples that would never be used in practice because they are needlessly complex when something much simpler would do the same job. If you can't figure out why that code example does not toggle the number, then that's a perfect example of something that is needlessly complex.

I understand that, that what I figure out, is to rearrange the order of sequence, to witch why I repost the code as working. But why?-------------------oease answer the original problem as directive. The rest is for doxumented report./* i think it only tgrow the type error when asigning 4 to num((num === 4)&&(num = ~-1))||((num === 0)&&(num = ~-5));it throws a type error: 4 is not a function((num === 4)&&(num = ~-3))||((num === 2)&&(num = ~-5));/*toggle between 1 and 4((num === 4)&&(num = ~-2))||((num === 1)&&(num = ~-5));toggle between -3 and 1((num === -3)&&(num = ~-2))||((num === 1)&&(num = ~2));toggle between -2 and 1((num === -2)&&(num = ~-2))||((num === 1)&&(num = ~1));does not toggle((num === -2)&&(num = ~-1))||((num === 0)&&(num = ~1));toggle 1 and 0((num === 1)&&(num = 0))||((num === 0)&&(num = 1));toggle between -4 and 3((num === 3)&&(num = ~3))||((num === -4)&&(num = ~-4));toggle between -4 and 3((num === -4)&&(num = ~-4))||((num === 3)&&(num = ~3));toggle between -2 and 1((num === -2)&&(num = ~-2))||((num === 1)&&(num = ~1));does not toggle((num === 1)&&(num = ~-1))||((num === 0)&&(num = ~-2));toggle between 1 and -2 if i remember((num === 1)&&(num = ~1))||((num === ~1)&&(num = ~~1));toggle between -2 and 1 guess the rest((num === ~1)&&(num = ~~1))||((num === 1)&&(num = ~1));((num === ~1)&&(num = ~-2))||((num === 1)&&(num = ~1));((num === -2)&&(num = ~-2))||((num === 1)&&(num = ~1)); //var num = 1;((num === 0)&&(num = ~-2))||((num === 1)&&(num = ~-1));*//*((num ===-3)&&(~num))||((num === 2)&&(~num)); //var num = 1;((num === (~1))&&(~num))||((num === 1)&&(~num));*/ //var num = 1;/*((num === 1)&&(~num))||((num === ~1)&&(~~num));*//* var num = 1;((num === 1)&&(--num))||((num === 0)&&(++num));*/;

[thescientist]

And I see you didn't read my post about experimenting, getting to understand how the simple feature work

Nothing that you posted would be considered a simple feature though. Just complex, hard to read, impractical sample snippets. That's all we've been trying to tell you. basic loops, control structures, events, etc are simple features.

[justsomeguy]

Seriously, this entire discussion is a great example of why simple code is best. You are trying to implement this:

toggle = !toggle;

with this:

((num === 1)&& --num)||((num === 0) && ++num)

I mean, just look at the efficiency of it. Other than assignment, your version uses a minimum of 3 operators, and a maximum of 5. Mine always only uses 1.If you want to know why it doesn't work, then just trace through the code when num is 1. It looks at the first expression, which evaluates to true, since num is 1. Then it goes to the second one, does a pre-decrement, which sets num to 0, then tests it. It evaluates to false because num is 0. So that entire AND expression evaluates to false, so it moves to the or. It checks the first expression, if num is 0, and it's now 0, so that's true, and then it does the last expression, setting num back to 1. So num is only 0 between the decrement and the increment. You should be able to follow that logic as a programmer, you should be able to look at that line of code and follow it through to figure out what it does. But in this case you shouldn't need to, because when I run across that in your code I delete it and replace it with toggle = !toggle, so that everyone knows exactly what is going on (and it happens more efficiently).And if you want to toggle between any 2 arbitrary values a and b, then use one of those:

if (x === a) {  x = b;} else {  x = a;}

x = (x === a ? b : a);

Either of those are far more readable and efficient then all of the crap you're posting above. You're trying to get cute with bitwise and logical operators when they are completely unnecessary. They have a place, but not how you're using them.

[L8V2L]

Nothing that you posted would be considered a simple feature though. Just complex, hard to read, impractical sample snippets. That's all we've been trying to tell you. basic loops, control structures, events, etc are simple features.

Understanding the side effects of operation is important. Consider the two:If(foo===bar){fooBar();}Same as:(foo===bar)&&(fooBar());Both have the same effects. Just different operation. This is important to other stand....And one more thing, there is a lot of mistake and incorrect wording in the tutorials. Woah at least let you guys fix the errors.

[L8V2L]

Seriously, this entire discussion is a great example of why simple code is best. You are trying to implement this:

toggle = !toggle;

with this:

((num === 1)&& --num)||((num === 0) && ++num)

I mean, just look at the efficiency of it. Other than assignment, your version uses a minimum of 3 operators, and a maximum of 5. Mine always only uses 1.If you want to know why it doesn't work, then just trace through the code when num is 1. It looks at the first expression, which evaluates to true, since num is 1. Then it goes to the second one, does a pre-decrement, which sets num to 0, then tests it. It evaluates to false because num is 0. So that entire AND expression evaluates to false, so it moves to the or. It checks the first expression, if num is 0, and it's now 0, so that's true, and then it does the last expression, setting num back to 1. So num is only 0 between the decrement and the increment. You should be able to follow that logic as a programmer, you should be able to look at that line of code and follow it through to figure out what it does. But in this case you shouldn't need to, because when I run across that in your code I delete it and replace it with toggle = !toggle, so that everyone knows exactly what is going on (and it happens more efficiently).And if you want to toggle between any 2 arbitrary values a and b, then use one of those:

if (x === a) {  x = b;} else {  x = a;}

x = (x === a ? b : a);

Either of those are far more readable and efficient then all of the crap you're posting above. You're trying to get cute with bitwise and logical operators when they are completely unnecessary. They have a place, but not how you're using them.

//But this variation works:((num === 0)&& ++num)||((num === 1) && --num);

[justsomeguy]

Both have the same effects.

Yeah they do have the same effects. Except when they don't, of course, which is the bug in your original code. This code:

((num === 1)&& --num)||((num === 0) && ++num)

is absolutely not the same as an if statement. An OR operator is not a replacement for an if statement. It is important for you to understand that. It can substitute for an if statement in CERTAIN SITUATIONS, but not all of them, because with an or operator it will execute both expressions if the first one is false. With an if/else, it only ever executes one block.

[justsomeguy]

But this variation works:((num === 0)&& ++num)||((num === 1) && --num);

Yeah, it does, sort of, even though that last expression evaluates to false. This is why you should not try and get cute with the OR and AND operators. This is the truth table for an OR operator:

A   B   OR0   0   01   0   10   1   11   1   1

Look at that, A OR B is the same as B OR A. They have the same result. That's called transitivity. OR is a transitive operation. But, what happened with your code? You're trying to use OR to replace an if statement, but if you switch the order of the expressions the result changes. You broke transitivity because you're trying to use OR to replace an if statement, which is absolutely not the point of OR. And all of this because you are apparently trying to find the most complicated way to toggle between 2 values, which should be a very simple and fast operation.

[L8V2L]

Yeah, it does, sort of, even though that last expression evaluates to false. This is why you should not try and get cute with the OR and AND operators. This is the truth table for an OR operator:

A   B   OR0   0   01   0   10   1   11   1   1

Look at that, A OR B is the same as B OR A. They have the same result. That's called transitivity. OR is a transitive operation. But, what happened with your code? You're trying to use OR to replace an if statement, but if you switch the order of the expressions the result changes. You broke transitivity because you're trying to use OR to replace an if statement, which is absolutely not the point of OR. And all of this because you are apparently trying to find the most complicated way to toggle between 2 values, which should be a very simple and fast operation.

var num = 0;((num === 1)&& --num)||(++num);num = 1;((num === 0)&& ++num)||(--num);/*This is code done after I saw you're message*//* im guessing or in better of a term, my conculsion is this: as && work, both side have to be true, if not, its false, any other value in numeric speaking is true, but zero, so when it evaluate to zero it becomes false and no effect is taking. one other mistory is that, what of ||... or maybe as you said JSG, that it does evulate but then is converted back cause the && become fault as so the or takes over and increament it.((num === 0)&& ++num)||eval(--num);/*this work:((num === 0)&& ++num)||(function(){return(--num);})();this mistake i made toggle((num === 1)&& ++num)||(function(){return(--num);})();does not work((num === 1)&&(function(){return(--num);})())||(++num);does not work((num === 1)&& function foo(){return(--num);})||(++num);*/

/*I'm guessing or in better of a term, my conculsion is this: as && work, both side have to be true, if not, its false, any other value in numeric speaking is true, but zero, so when it evaluate to zero it becomes false and no effect is taking. one other mistory is that, what of ||... or maybe as you said JSG, that it does evulate but then is converted back cause the && become fault as so the or takes over and increament it.*/((num === 0)&& ++num)||eval(--num);/*&& ||1 == true0 == false1&&0(--num == 0 == false)||1 eval();1&&1(++num==1==true)||non-eval();*//*this work:((num === 0)&& ++num)||(function(){return(--num);})();this mistake i made toggle((num === 1)&& ++num)||(function(){return(--num);})();does not work((num === 1)&&(function(){return(--num);})())||(++num);does not work((num === 1)&& function foo(){return(--num);})||(++num);*/

------------------------------------------The code below is before I read your comment:

/*does toggle((num === 0)&&(++num))||eval(--num);doesn't toggle((num === 1)&& eval(--num))||(++num);but as you can see wirh this it does not work((num === 1)&& --num)||(++num);here is a more incise version:((num === 0)&& ++num)||(--num);((num === 1)&& --num)||((num === 0) && ++num)*//*((num === 1)&& eval(--num))||(++num);but as you can see wirh this it does not work((num === 1)&& --num)||(++num);here is a more incise version:((num === 0)&& ++num)||(--num);((num === 1)&& --num)||((num === 0) && ++num)*/

[justsomeguy]

I don't even know what to say. All of this is needlessly complex and terrible practice, and you decide to throw eval in for good measure? Yikes. eval does absolutely nothing in that context, by the way. What's the point of eval(0) or eval(1)? There's no point. You might have a future in code obfuscation contests.I'm reminded of this commercial.

That's not how it works! That's not how any of this works!