Content deleted Content added
Z. Patterson (talk | contribs) No edit summary |
|||
| (63 intermediate revisions by 29 users not shown) | |||
Line 1:
{{Talk header}}
{{WikiProject banner shell|class=C|
{{WikiProject Computing |importance=Mid |software=y |software-importance=Mid}}
{{WikiProject JavaScript|importance=Top}}
}}
{{American English}}
{{Backwardscopy
|author = Miller, F. P., Vandome, A. F., & McBrewster, J.
|year = 2010
|title = JavaScript: JavaScript syntax, client-side JavaScript, JavaScript engine, Ajax (programming), Web interoperability, web accessibility, cross-site scripting, cross-site request forgery, ECMAScript, dynamic HTML
|org = Alphascript Publishing
|comments = {{OCLC|721316846}}, {{ISBN|9786130097844}}.
|bot=LivingBot
}}
{{Broken anchors|links=
* <nowiki>[[Grave accent#Use in programming|backquote]]</nowiki> The anchor (Use in programming) [[Special:Diff/1083439356|has been deleted]]. <!-- {"title":"Use in programming","appear":null,"disappear":{"revid":1083439356,"parentid":1081031463,"timestamp":"2022-04-18T20:37:32Z","removed_section_titles":["As surrogate of apostrophe or (opening) single quote","CITEREFKuhn2001","CITEREF2019","CITEREFEggert2012","Technical notes","ASCII grave","Games","Use in programming","CITEREFOdersky2011"],"added_section_titles":["Unicode"]}} -->
}}
== Inaccuracy (needs citation) ==
The following statement: "'''else statements must be cuddled (i.e. "} else {" , all on the same line), or else some browsers may not parse them correctly.'''" found in section 5.1 is incorrect. I have been programming in javascript for 4 years, and have never used that programming style. I have yet to notice any browser incompatibilities. If this statement is true, please provide a citation. - [[User:Kickboy|Kickboy]] 04:07, 24 August 2006 (UTC)
:The statement is not present anymore.
:Can we delete this block from 2006? [[Special:Contributions/87.191.37.170|87.191.37.170]] ([[User talk:87.191.37.170|talk]]) 07:26, 9 December 2022 (UTC)
== Inheritance without prototyping, etc. ==
Line 99 ⟶ 117:
Should it not be explained that the following:
<
if(x==1){
something()
Line 106 ⟶ 124:
somethingelse();
}
</syntaxhighlight>
the else if works like a shorthand if (without {})
<
if(x==1)
do something here
Line 122 ⟶ 140:
}
}
</syntaxhighlight>
Sorry if that didn't make sense, I find it hard to explain.
: To me, this is an implementation detail. Can you give an example of different behavior (from programmer point of view) between <code>else { if(...){ } }</code> and <code>elsif(...){ }</code> constructions? — [[User:Hypher|Hypher]] ([[User talk:Hypher|talk]]) 08:38, 20 March 2011 (UTC)
== Bitwise ==
Line 134 ⟶ 154:
== For loop: end-condition? ==
<
for (initial;end-condition;loop statement) {
/*
Line 142 ⟶ 162:
*/
}
</syntaxhighlight>
The condition should be called ''while-condition'', or just ''condition'', but never ''end-condition''. As in every C-like language, the for{} loop cycles '''while''' the condition is satisfied. --[[User:Comocomocomocomo|Como]] ([[User talk:Comocomocomocomo|talk]]) 14:28, 23 October 2008 (UTC)
No response in several months... I assume everyone agrees, so I dared to change the article. --[[User:Comocomocomocomo|Como]] ([[User talk:Comocomocomocomo|talk]]) 09:26, 3 March 2009 (UTC)
: with no doubt
:<code> for(initial; condition; loopstatement) s; </code>
: is indeed syntactic sugar for
:<code> initial; while(condition){ s; loopstatement; } </code> <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/201.124.237.242|201.124.237.242]] ([[User talk:201.124.237.242#top|talk]]) 09:05, 25 December 2019 (UTC)</small> <!--Autosigned by SineBot-->
== Reworked Methods and Inheritance ==
Line 174 ⟶ 199:
Internet explorer uses JScript, not JavaScript, it works with all JavaScript browsers. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 19:10, 4 March 2011 (UTC)
:No, JScript, at this time, is ECMAScript 3, so is JavaScript 1.5. Confirmed by Wikipedia via a quote from Douglas Crockford: http://en.wikipedia.org/wiki/JScript#Comparison_to_JavaScript . --[[User:Hibou57|Hibou57]] ([[User talk:Hibou57|talk]]) 20:09, 18 July 2013 (UTC)
== alert vs. println ==
Line 184 ⟶ 210:
:Thanks for the response Maian. It's very difficult to create demonstrable JavaScript examples with the lack of a standard output function. After so many hours coding in this sometimes great, sometimes atrocious language, I figured I'd err on the side of making things browser compliant. [[User:Jeremywosborne|Jeremywosborne]] ([[User talk:Jeremywosborne|talk]]) 20:09, 22 April 2009 (UTC)
I use alert a lot. Why println? [[User:ElliottBelardo|ElliottBelardo]] ([[User talk:ElliottBelardo|talk]]) 21:03, 8 July 2013 (UTC)
== Functions ==
Line 189 ⟶ 217:
The code could be changed to also illustrate the ternary operator <tt>? :</tt> :
<
return diff > 0 ? gcd(segmentB, diff) : gcd(segmentA, -diff)
</syntaxhighlight>
Since the code might be copied, it would be well to change it, after testing, to the more efficient method, in which the second argument to the internal <tt>gcd</tt> is either <tt>A mod B</tt> or <tt>B mod A</tt>, which is approximately equally easy to read; or to the wondrous non-recursive form :
<
function GCD(U, V) { // or HCF
while (true) {
if (!(U %= V)) return V
if (!(V %= U)) return U } }
</syntaxhighlight>
And, for the same reason, the alternative acronym HCF should be included. [[Special:Contributions/82.163.24.100|82.163.24.100]] ([[User talk:82.163.24.100|talk]]) 20:01, 24 July 2009 (UTC)
Line 234 ⟶ 262:
WHERE ARE THE RULES FOR ALL THE LEGAL BUT WIERD CHARACTERS IN IDENTIFIERS? (e.g. "$", "_", etc) <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/24.129.93.200|24.129.93.200]] ([[User talk:24.129.93.200|talk]]) 16:29, 16 September 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot--> {{small|''([[WP:REFACTOR|moved to new section]])''}}
:Added to [[JavaScript_syntax#Variables]]: "An identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9). Because JavaScript is case sensitive, letters include the characters "A" through "Z" (uppercase) and the characters "a" through "z" (lowercase). Starting with JavaScript 1.5, you can use [[ISO 8859-1]] or [[Unicode]] letters (or \uXXXX Unicode escape sequences) in identifiers."—[[User:Machine Elf 1735|Machine Elf 1735]] ([[User talk:Machine Elf 1735|talk]]) 00:18, 17 September 2010 (UTC)
Machine Elf’s edit is a good start, but it’s not entirely accurate. Digits aren’t limited to 0-9 — any character in the “Decimal digit number (Nd)” Unicode category is considered a digit. Also, a lot more characters/categories are allowed in identifiers. See http://mathiasbynens.be/notes/javascript-identifiers by Mathias Bynens: “An identifier must start with $, _, or any character in the Unicode categories “Uppercase letter (Lu)”, “Lowercase letter (Ll)”, “Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”, or “Letter number (Nl)”. The rest of the string can contain the same characters, plus any U+200C zero width non-joiner characters, U+200D zero width joiner characters, and characters in the Unicode categories “Non-spacing mark (Mn)”, “Spacing combining mark (Mc)”, “Decimal digit number (Nd)”, or “Connector punctuation (Pc)”.” There’s also a JavaScript variable name validator tool here: http://mothereff.in/js-variables
[[Special:Contributions/78.20.165.163|78.20.165.163]] ([[User talk:78.20.165.163|talk]]) 11:29, 5 March 2012 (UTC)
== Truthy and Falsey ==
"Truthy" and "Falsey"... feel free to source them and say something about them.—[[User:Machine Elf 1735|Machine Elf 1735]] ([[User talk:Machine Elf 1735|talk]]) 01:09, 5 March 2011 (UTC)
== Boolean section ==
I propose the boolean section be edited to be less confusing. I also propose that the ternary operator be removed from the section, because logical context is being misrepresented as type coercion, which it is not. The ternary (?:) operator is not an example of type coercion, nor is the negation operator "!". Furthermore, the page compares expressions instead of values, as there are infinite expressions, all unessential expressions should be removed from the section for clarity. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 06:36, 6 March 2011 (UTC)
:Considering I've removed examples like <code>true==true</code> and <code>false==false</code>... if you have something specific in mind, please share, otherwise you're not ''proposing'' proposing anything in your opening sentence. I think it's a lot less confusing than it was {{diff2|417184592|here}}:
<div style="font-size:75%;line-height:150%;margin-left:2.5em;padding-bottom:1.5em;">
<syntaxhighlight lang="JavaScript">
// Automatic type coercion
//Boolean operands will be converted to a number, if possible, or to a string (if the other is a string)
alert(false == false); // true
alert(false == 0); // true
alert(false == "0"); // true
alert(true == true); // true
alert(true == 1); // true
alert(true == "1"); // true
// Type checked comparison
// No conversion of values
alert(false === false); // true
alert(false === 0); // false
alert(false === "0"); // false
alert(true === true); // true
alert(true === 1); // false
alert(true === "1"); // false
</syntaxhighlight>
Examples with "falsy" and "truthy" values.
<syntaxhighlight lang="JavaScript">alert(3?true:false); // true
alert(true == 3); // false
// 3 is logically true(known as "truthy"), as are all non-0 non-nan numbers. However, it is not "true", even with type coercion.
alert(!!null == false); // true
alert(null == false); // false
// Two exclamation marks will convert anything into a boolean based on if it is truthy or not. However, automatic type coercion does not convert to booleans. null is falsy but not "false".
alert(false == +'NaN'); // false (shorthand for getting a NaN value)
</syntaxhighlight>
</div>
:I think some of the permutations could potentially be eliminated but it's necessary to show, for example, that neither <code>true==2</code> nor <code>false==2</code> behave the way one might expect.
:The ternary operator's clearly appropriate for an overview of logical operations, Booleans, and automatic conversion. Are you seriously suggesting negation shouldn't be used?
:{{small|“{{gray|Furthermore, the page compares expressions instead of values...}}”}}
::It obviously does both.
:If you have constructive suggestions to enhance it's clarity, I'd like to hear them.—[[User:Machine Elf 1735|Machine Elf 1735]] ([[User talk:Machine Elf 1735|talk]]) 08:33, 6 March 2011 (UTC)
{{unindent|:}}
You have too many examples, they don't demonstrate the important points. Logical context needs it's own section, it's a feature of the syntax, not of automatic type coercion by the equality operator. "that neither <code>true==2</code> nor <code>false==2</code> behave the way one might expect." That was already demonstrated. Type conversion by the ! operator is not the same as automatic type coercion. Again, these edits are harmful to the clarity of the article. Each aspect was demonstrated well before your edit. Type coercion was shown, as well as logical context. Each in their own separate code box. Let's not jumble two entirely different features of javascript into one box. That is definitely cause for confusion. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 16:35, 6 March 2011 (UTC)
PS: I may add that the ! operator belongs in the "Operators" section, not to booleans. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 16:42, 6 March 2011 (UTC)
:As I said, I agree that some of the examples can be eliminated. I simply included the permutations because that's what you did... Needlessly, you more than quadrupled the original four examples: 1 and "0" for each.
:Contrary to what you keep repeating, you did '''''not''''' provide an example that clearly demonstrates the behavior of a Boolean operand being automatically converted to number for comparison. Frankly, the terms "truthy" and "falsy" were irrelevant except in so far as the behavior is somewhat counter-intuitive:
:In an equality comparison (non-strict, obviously) between a Boolean (on one side) and either a number or a string (on the other), the Boolean operand is converted to a number, rather than the non-Boolean operand being converted to a Boolean. Thus, a comparison between a Boolean and any number except 0, 1, (and NaN), or any non-empty string that can't be converted ''specifically'' to 1, (e.g. "0", "2", "3"...), won't behave consistently with the non-Boolean operand's so-called "truthy"/"falsy" behavior in logical contexts. For example, 2 is "truthy", (as in <code>2?true:false</code>), but ''neither'' <code>true==2</code> ''nor'' <code>false==2</code> are true, because the Boolean is automatically converted to 1, and neither <code>1==2</code> nor <code>0==2</code> are true.
:In addition to your 12 permutations of automatic v. strict comparison, you added a separate block: “Examples with "falsy" and "truthy" values”, making a peculiar example of the number 3, (rather than 2). In a line comment you say: “3 is logically true(known as "truthy"), as are all non-0 non-nan numbers. However, it is not "true", even with type coercion.” '''[''sic'']'''
:In a Boolean context, ''3 '''is''' always "true".'' Comparison is ''not'' a Boolean context. And comparison to a Boolean does ''not'' make it a Boolean context any more than comparison to a number makes it a numeric context, or comparison to a string makes it a string context. When 3 ''does'' get type converted ''(automatically or explicitly)'' to a Boolean, ''then'' it's always <code>true</code>, and never <code>false</code>, (whether or not that Boolean then gets discarded in favor of the original value, and so, arguably, wasn't so much "converted" as "interpreted"... just isn't the point.)
:If you say <code>3?true:false</code> is true and <code>true==3</code> is false; you invite the assumption that <code>false==3</code> is true, but '''that's ''false'' too.''' So no, you're mistaken when you say “That was already demonstrated.”
:I'm not going to argue with you about whether logical context needs its own section, but it's clear to me that you do ''not'' understand “automatic type coercion by the equality operator”.
:Your suggestion not to use the negation and ternary operators is inexplicable considering that you, yourself, used the ternary to demonstrate the so-called "truthiness" of 3, and double negation to show an explicit ''(obviously)'' conversion of a null to a Boolean. The suggestion that examples in the Boolean section should exclude these operators is just kind of strange and unhelpful, isn't it?
:I'll give you an example of an edit “harmful to the clarity of the article”, your misleading comment: “shorthand for getting a NaN value”. Any string that can't be converted to a number would result in NaN, <code>+"NaN"</code> ''is not shorthand,'' <code>NaN</code> is shorthand.
{{small|{{small|“{{grey|Each aspect was demonstrated well before your edit. Type coercion was shown, as well as logical context. Each in their own separate code box. Let's not jumble two entirely different features of javascript into one box. That is definitely cause for confusion.}}”}}}}
:Argument by repetition isn't constructive. I think the section was fine before ''your'' last edit. And I think it demonstrating type conversion/coercion and various logical contexts... However, the examples didn't attempt to address the edge case ''which you made a point of in your edit.''
:You don't seem to understand the issue and so your examples were misleading. It's also clear you don't get it from: {{small|“{{gray|Each in their own separate code box ... Let's not jumble two entirely different features of javascript into one box}}”}}. Demonstrating strict v. non-strict comparison doesn't require 12 examples (four was more than enough). The edge case is when Boolean and non-Boolean operands are used in a non-strict comparison but what you said was: {{small|“{{gray|Examples with "falsy" and "truthy" values.}}”}}. Now, when you say {{small|“{{gray|demonstrated well before}}”}}, I suppose you think that ''you'' demonstrated each aspect, (and ''well,'' if you do say so yourself), otherwise, why would you more than quadruple the number of examples, if you thought each aspect had been demonstrated long ago? Still, your edit wasn't all bad, the "truthy"/"falsy" jargon is nice to have... It's just that you can't give examples of it with no introduction.
:The section is about Booleans. As we all know, they're closely related to logical contexts. The section is ''not'' about type conversion. The section is ''not'' about automatic v. strict operators. The section is ''not'' about implicit v. explicit conversions. If you'd stop trying to twist it into something it's ''not,'' I'll remove some of the unnecessary permutations.—[[User:Machine Elf 1735|Machine Elf 1735]] ([[User talk:Machine Elf 1735|talk]]) 08:53, 7 March 2011 (UTC)
Try to make your posts more compact.
First: I said it is not "true" which means it does not == true. Truthy is not the same as true. Type coercion generally refers to the == operator, type conversion relates to the not operator, boolean function, etc. Also, note that you added most of the example. The section is about booleans, and how booleans behave in each context, in context of conversions, type equality, and such. It is not about the not operator. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 01:02, 8 March 2011 (UTC)
PS: "Contrary to what you keep repeating, you did not provide an example that clearly demonstrates the behavior of a Boolean operand being automatically converted to number for comparison." How about "alert(true == 1)" ? That looks like a good example to me. You seem to have trouble noting these things. [[Special:Contributions/72.152.120.17|72.152.120.17]] ([[User talk:72.152.120.17|talk]]) 01:04, 8 March 2011 (UTC)
== Function example code misleading ==
<syntaxhighlight lang="JavaScript">
var obj1 = {a : 1};
var obj2 = {b : 2};
function foo(p) {
p = obj2; // ignores actual parameter
p.b = arguments[1];
}
foo(obj1, 3); // Does not affect obj1 at all. 3 is additional parameter
alert(obj1.a + " " + obj2.b); // writes 1 3
</syntaxhighlight>
This is misleading because obj1 can be modified by the function. It is quite odd (in an explanation) to pass a parameter to a function and then ignore it.
Consider:
<syntaxhighlight lang="JavaScript">
var obj1 = {a : 1};
var obj2 = {b : 2};
function foo(p) {
p.a = 7; // modifies global variable obj1
p = obj2; // no effect on obj1, ignores actual parameter
p.b = arguments[1];// modifies global variable obj2
}
foo(obj1, 3); // Does affect obj1. 3 is additional parameter
alert(obj1.a + " " + obj2.b); // writes 7 3
</syntaxhighlight>
Because the object parameter is passed by reference it can be modified.
This is OR for me. I am just learning. But I was surprised that obj1 can be modified in the function, by p.a=7, yet p=obj2 does not affect obj1. This should be explained. [[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 02:27, 28 June 2011 (UTC)
== Some of the primitive data types also provide a set of named values that represent the extents of the type boundaries. These named values are described within the appropriate sections below. ==
Is this a long winded way of saying "null, Infinity, NaN, true, false"? What other boundary values are there? [[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 11:49, 21 July 2011 (UTC)
:Number.MIN_VALUE and Number.MAX_VALUE come to mind: the global properties Infinity and NaN (same as Number.POSITIVE_INFINITY and Number.NaN, there's also Number.NEGATIVE_INFINITY) are a bit philosophical... they're ''special'' values with particular results specified for comparisons/casts/calculations. (I think true, false, and null are keywords as opposed global properties). I would definitely remove the generalization.—[[User talk:Machine Elf 1735|<span style="text-shadow:#00FADE 0.05em 0.05em 0.07em;white-space: nowrap;font-family: Fraktur, Mathematica6, Georgia, sans-serif">Machine Elf <sup style="font-size:75%;font-family: Georgia, sans-serif">1735</sup></span>]] 01:22, 24 July 2011 (UTC)
::These are not mentioned so the initial statement is misleading. Also there is a range of numbers between Number.MAX_VALUE and Number.POSITIVE_INFINITY, "so boundaries" is also misleading. [[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 03:27, 25 July 2011 (UTC)
== Strings ==
I've seen strings defined as
var greetings = /Hello World!/
what's going on here, ie how come this is not mentioned in the article.
[[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 12:08, 21 July 2011 (UTC)
:It's a regular expression object literal.—[[User talk:Machine Elf 1735|<span style="text-shadow:#00FADE 0.05em 0.05em 0.07em;white-space: nowrap;font-family: Fraktur, Mathematica6, Georgia, sans-serif">Machine Elf <sup style="font-size:75%;font-family: Georgia, sans-serif">1735</sup></span>]] 01:22, 24 July 2011 (UTC)
== Split Boolean ==
One problem with this article is that you can not read it from start to end. ie In the Boolean section it discusses the == operator and the || and && operators before they and their odd behaviour are mentioned.
// That the following are different surprised me:-
alert(2 && true); // true
alert(true && 2); // 2
// also
alert(2==2==1); // true
alert(1==2==2); // false
// But if the rules were explained first they wouldn't have.
[[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 17:39, 21 July 2011 (UTC)
:I got tired of reverting an obnoxious IP who didn't understand coercion issues. For whatever reason, they were fixated on the section about the Boolean constructor but should have focused on the sections about the operators... comparison, assignment, conditional, logical... [[User talk:Machine Elf 1735|<span style="text-shadow:#00FADE 0.05em 0.05em 0.07em;white-space: nowrap;font-family: Fraktur, Mathematica6, Georgia, sans-serif">Machine Elf <sup style="font-size:75%;font-family: Georgia, sans-serif">1735</sup></span>]] 01:22, 24 July 2011 (UTC)
== Unlike C, whitespace in JavaScript source can directly impact semantics. ==
1) In C whitespace is important for pre-processing.
2) In C++ whitespace in needed for nested templates > > otherwise this becomes >> a shift
[[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 17:20, 21 July 2011 (UTC)
:As in "how so"? Offhand, semicolon insertion, escaping line terminators in string literals, stray byte order marks... js doesn't normalize Unicode equivalents, strings are just so-many 16-bit unsigned integers.—[[User talk:Machine Elf 1735|<span style="text-shadow:#00FADE 0.05em 0.05em 0.07em;white-space: nowrap;font-family: Fraktur, Mathematica6, Georgia, sans-serif">Machine Elf <sup style="font-size:75%;font-family: Georgia, sans-serif">1735</sup></span>]] 01:22, 24 July 2011 (UTC)
:: It is not unlike C in this respect. So the statement that it is unlike C is incorrect. [[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 03:18, 25 July 2011 (UTC)
::: I don't know JavaScript, I saw some code with some lines starting with a semicolon, I wrongly interpreted it as a line comment like the // in C++ because other languages, like several assemblers and Lisp, treat semicolon as a line comment.
:::I learned from this article that JavaScript has an ambiguous syntax with this respect.
:::Syntax ambiguities ''should be a section'' in the article, although I think that the whole article should be rewritten focusing on the syntax of the language.
== Strict equals transitivity ==
The following
<syntaxhighlight lang="JavaScript">
alert( !0 === Boolean( !0 ) === !!1 === Boolean( 1 ) === true );
alert( !!0 === Boolean( 0 ) === !1 === Boolean( !1 ) === false );
alert( !"" === Boolean( !"" ) === !!"s" === Boolean( "s" ) === true );
alert( !!"" === Boolean( "" ) === !"s" === Boolean( !"s" ) === false );
</syntaxhighlight>
Gives the impression that equality can be chained together. A===B===C being true when they are all equal, this is not the case. [[User:QuentinUK|QuentinUK]] ([[User talk:QuentinUK|talk]]) 10:57, 11 August 2011 (UTC)
== Variable declaration ==
In the "Variable" section, shouldn't there be a word about usage of the keyword '''var'''? What happens when you use it? What happens when you don't?
Also, the section on semicolons reads like a personal blog and contains a reference to an outside blog. <font style="font-family:Monotype Corsiva; font-size:18px">--[[User:Timsabin|Tim Sabin]] ([[User talk:Timsabin#top|talk]])</font> 17:58, 13 April 2012 (UTC)
== Assignment Examples -- Primitive Types ==
The examples for -= and /= (shorthand for non-commutative operations) don't currently allow the reader to infer the order of the operations. If we start with x=3, it isn't clear why the result of x /= 3 is 1. Was it because x was divided by 3, or because 3 was divided by x? For this reason I am changing the numerical values in the example sequence. [[User:Evaluist|Evaluist]] ([[User talk:Evaluist|talk]]) 22:42, 15 November 2012 (UTC)
== Testing for `undefined` ==
Unless some one sees an issue with it, I will add this to the way to check for the `undefined` special value:
function isUndefined (o) {
return ((typeof o) === "undefined");
}
Seems the way using `typeof` is missing in the document.
--[[User:Hibou57|Hibou57]] ([[User talk:Hibou57|talk]]) 19:25, 18 July 2013 (UTC)
== Doesn't mention ES6's "spread operator": ... ==
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator MDN] and [https://msdn.microsoft.com/en-us/library/dn919259(v=vs.94).aspx MSDN] both talk of a spread operator, written "..." and it's not covered here or on other places I've been able to find on Wikipedia about JS or ES6. Then again I've been told that even though major JS sources call ... an [[operator]] it may not technically be an operator. — [[User:Hippietrail|Hippietrail]] ([[User talk:Hippietrail|talk]]) 06:08, 27 January 2016 (UTC)
: I took a try at creating [https://en.wikipedia.org/w/index.php?title=JavaScript_syntax&oldid=741715358#Spread.2Frest_operator a section] about the spread/rest operator "<tt>...</tt>". I placed it in the section on operators, although now that I think about it, it's probably true that it's not an "operator" in the strict sense. It's more like syntactic punctuation, along the same lines as "[]", "{}", commas, and semicolons. In which case, rest parameters should perhaps be moved into the section on functions, and spread syntax should be moved into the section on arrays (and maybe also mentioned in the section on funcions). --[[Special:Contributions/2404:130:0:1000:102E:358C:1F00:94A4|2404:130:0:1000:102E:358C:1F00:94A4]] ([[User talk:2404:130:0:1000:102E:358C:1F00:94A4|talk]]) 06:48, 29 September 2016 (UTC)
== Maintenance and rating of JavaScript articles ==
Concerning editing and maintaining JavaScript-related articles...
=== Collaboration...===
If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by [[Wikipedia:WikiProject JavaScript]] and feel free to add your name to the participants list. Both editors and programmers are welcome.
=== Where to list JavaScript articles ===
We've found over 300 [[Index of JavaScript-related articles|JavaScript-related articles]] so far. If you come across any others, please add them to that list.
=== User scripts ===
The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), [[Wikipedia talk:WikiProject JavaScript|let us know]]!
If you have need for a user script that does not
yet exist, or you have a cool idea for a user script or gadget, you can post it at [[Wikipedia:User scripts/Requests]]. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.
=== How to report JavaScript articles in need of attention ===
If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our [[Wikipedia:WikiProject JavaScript#JavaScript-related articles that need attention|list of JavaScript-related articles that need attention]].
=== Rating JavaScript articles ===
At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.
Thank you. [[User talk:The Transhumanist|<i>The Transhumanist</i>]] 01:10, 12 April 2017 (UTC)
== Comments Please ==
I thought the commenting on the examples was very good up until the last example in the Function session & several in the Objects section. Without having the ability to set breakpoints to follow the logic, I had trouble understanding what the author wanted to demonstrate.
I don't know if my sentiment is widespread because I am self-taught and may have missed some implied points along the way. Otherwise, I thought it was well-done. [[User:The Source Whisperer|The Source Whisperer]] ([[User talk:The Source Whisperer|talk]]) 03:58, 6 May 2019 (UTC)
== With statement listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] ==
[[File:Information.svg|30px|left]]
An editor has asked for a discussion to address the redirect [[With statement]]. Please participate in [[Wikipedia:Redirects for discussion/Log/2019 May 19#With statement|the redirect discussion]] if you wish to do so. <!-- from Template:RFDNote --> — [[User:Arthur Rubin|Arthur Rubin]] [[User talk:Arthur Rubin|(talk)]] 10:56, 19 May 2019 (UTC)
== This '''is not the JavaScript syntax''' is a very long description of the language ==
A programming language syntax is a set of grammar rules which produce any correct written program in the given language. i.e. a program that the compiler/interpreter can analyse (parse) to translate.
It doesn't mean that a grammar produces code with no "bugs", vgr. <code>for(i=m; i<n; 0++)</code> is syntactically correct although evidently meaningless because that program never stops.
A rule restricting <math>m<n</math> and the appropriate increment which will make <code>i<n</code> false to end the loop, ''is semantic, not syntactic''.
Such rules are usually described by means of [[BNF]] grammars or [[syntax diagram]]s.
The article may also include a semantic description of each program construct. (Semi-formal of formal if there is one.)
I don't know JavaScript, but I doesn't seem a monster like [[C++]] with about 300 keywords.
It seems to be a much smaller one, which can be described in a more short article.
'''I agree that this article is too long, but the solution is not to fragment it.''' Instead, should be written, one that meets what the title say '''JavaScript syntax''' or one that includes the semantics and rename it to ''JavaScript syntax and semantics''.
The article should start with the description of the atomic elements like a keyword list, legal variable and other user defined names, the syntax of numbers, and whatever plays the role of words in a sentence. Then the rule that describes a program, followed by each construct of a program. Because I don't know JavaScript, I can't say something more correct. Take it as a general guide for the volunteers that accept this mission.
The source of information can be the standard manual of the language if it exist, please so don't expect hundreds of references.
Just a list of manuals describing the evolution of the language, because some constructs appeared from the first version, others in later versions. It would be ridiculous to tag such article urging for more references. It is a simple task for an experienced JavaScript programmer with some formal education in IT. [[User:Elias|Elias]] ([[User talk:Elias|talk]]) 06:56, 25 December 2019 (UTC)
: {{re|Elias}}. Thumbing up. I agree the article must be shortened. I also suggest to move examples to a separate one.
: {{tq|i=1|[...] The article may also include a semantic description [..] }} It would be disastrous to the article as specs contain a lot (I mean A LOT) of elaborated [[Interface description language|IDL]] definitions for very simple language constructs. I stand for providing simple examples avoiding making article overly academic/specific. <span style="font-size: small" >[[User:Alexander_Davronov|<span style='color:#a8a8a8'>AXO</span><span style="color:#000">NOV</span>]] [[User talk:Alexander_Davronov|(talk)]] [[Special:Contributions/Alexander_Davronov|⚑]]</span> 08:35, 13 October 2020 (UTC)
== Module syntax ==
Module syntax which is the most basic thing of every JS interpreter is missing. I suggest to make section on how module system works per different implementations like browser/server(e.g. Google Chrome/Node.js). I suggest to avoid making it bloated as to address issue pointed out by {{u|Elias}}. <span style="font-size: small" >[[User:Alexander_Davronov|<span style='color:#a8a8a8'>AXO</span><span style="color:#000">NOV</span>]] [[User talk:Alexander_Davronov|(talk)]] [[Special:Contributions/Alexander_Davronov|⚑]]</span> 08:35, 13 October 2020 (UTC)
| |||