Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: "i = i|0" Date: Fri, 13 Jun 2014 12:12:23 +0200 Organization: PointedEars Software (PES) Lines: 174 Message-ID: <2714661.LRbm3SKrxb@PointedEars.de> References: <44f393c9-8b85-4da8-8618-6b11dd3954b2@googlegroups.com> <5398CC30.9020706@verizon.net> <2078529.Slc7CH7YZo@PointedEars.de> <2122350.lP4zVSTnZj@PointedEars.de> <1894582.2ZI1QNF3Jn@PointedEars.de> <5399D2AA.6010100@verizon.net> <2396275.g7lyTkyHjg@PointedEars.de> <20140612134628.144@kylheku.com> <2151521.roT7KvbrzH@PointedEars.de> <6de08f5b-6447-4394-9717-e15ccca7e175@googlegroups.com> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1402654347 24555 eJwNwgERwDAIA0BLpCOhyIFu+JfQ3T8fQSdclHN+NuUeRmIOmvtdWCnEl5ixZll6q7xWFGJfCOMQZg== (13 Jun 2014 10:12:27 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Fri, 13 Jun 2014 10:12:27 +0000 (UTC) User-Agent: KNode/4.12.4 X-User-ID: eJwNy9sBADEEBMCWiMdSjgj9l3A3/2Pi7A11c7W1VcbtoeVGv83ssYyjeW6IrQTxMmpmCtig1iLk1PlP15P6AGQLFlc= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg== X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. "Michael Haufe (TNO)" writes: >> The very fact that Wikipedia and Stack Overflow are being >> used as instruments of truth in this matter is slightly >> disturbing. > > In this newsgroup, I deem relevant the MDN, which says: (Again you have neglected to give proper reference. *Where* *exactly* on MDN have you read what you quoted? You are, at least by appearance, at least an aspiring scientist; you should know better than this [especially as I told you several times before].) MDN (Mozilla Developer Network) certainly is relevant; but it is a wiki as well. It was _not_ solely written by the people developing *Mozilla* JavaScript [0] (which is what [MDN] describes), so it cannot be authoritative in any way. The validity of the statements in it depend on the knowledge and experience of the people editing it, the time they can invest in doing that, and the diligence they can show. (Me included.) So, unsurprisingly, some invented terminology, and misleading, even fundamentally wrong statements can still be found there. What you quoted is a good example of that: > »JavaScript's dynamic capabilities include runtime > object construction, True; you can create new objects at runtime that can have properties that have not previously been defined: var foo = { bar: 42 }; // … foo[some_variable_value] = some_other_variable_value; > variable parameter lists, No, in the ECMAScript terminology ([ES] §13), JavaScript parameter lists are _not_ variable: it is not possible to change the name or number of formal parameters of a function at runtime without creating a new function (and even that is error-prone, see below). However, the length of *argument* lists of function *calls* ([ES] §§11.2.3 and 11.2.4) is: in general, you can pass more or less arguments to in a function call than the function has formal parameters, and you can access those arguments using the “arguments” object in function context. In this sense, the term “function” applies also to methods, properties of objects whose value is a reference to a callable object. But the method may throw an exception or return an error value if an unsupported number of arguments was passed. Some methods of built-in objects throw exceptions in that case [ES], many methods of host objects do (e.g., those specified in [DOM]). > function variables, What is a “function variable”? Neither the original JavaScript documentation ([DevEdge]) nor [ES] define this term. It appears to be an ad-hoc invention at MDN. It is correct to say that functions are first-class objects in ECMAScript implementations, including Mozilla JavaScript, in the sense that they can be both l-values and r-values. In that sense, in var f = function () {}; where (a reference to) a function is an r-value, “f” could be defined as being a “function variable”; but that is a very limited view of this language feature. For example, you can pass a reference to a function to another function or even the same function: function f (f2) { /* something */ } f(f); Here, “f” is _not_ a variable, it is a function name which becomes the name of a property of the global object; “f2” also is _not_ a variable, it is (the name of) a formal parameter of the function named “f”. And, does “f” cease to be a “function variable” when, as there is only dynamic type-checking in these implementations, it is assigned a non- function value? f = 23; The misconception might have occurred in the author(s) because up to including ECMAScript Edition 3 the creation of Function instances from /FunctionDeclaration/s was described as part of a process labeled “Variable Instantiation” (because it involves evaluating /VariableDeclaration/s as well; [ES3], §10.1.3) > dynamic script creation (via eval), This statement is at least debatable. eval() does not help creating a script dynamically. A value of the String type it is passed as argument is interpreted as an ECMAScript /Program/ ([ES], §15.1.2.1), taking into account the (Mozilla) JavaScript extensions of the ECMAScript grammar [MDN]. > object introspection (via for ... in), True, but insufficient; probably simplifying or historic, potentially misleading. A for-in statement can only show the *enumerable* properties that an object has and inherits. ([ES], §12.6.4) Methods introduced with ECMAScript Edition 5, namely Object.getOwnPropertyNames() ([ES], §15.2.3.4) – which considers non- enumerable properties, but ignores inherited ones –, Object.getOwnPropertyDescriptor() ([ES], §15.2.3.3) – which gives information about property attributes –, and __proto__ and its ES3+ counterpart Object.getPrototypeOf() ([ES], §15.2.3.2) – which allows to inspect the inherited ones –, allow for much deeper introspection. (Current JavaScript versions are implementations of ECMAScript Ed. 5 and the Ed. 6 Draft. [MDN]) > and source code recovery (JavaScript programs can decompile function > bodies back into their source text)« Wishful thinking, potentially misleading. That there is the *possibility* of this is a consequence of the fact that Function instances (objects created with a /FunctionDeclaration/, /FunctionExpression/ or the Function constructor) inherit a “toString” method from their prototype, the object initially referred to by τhe expression “Function.prototype”. That toString() method is specified in [ES] to return a string value that matches the /FunctionDeclaration/ production. However, no guarantee is given anywhere in the original JavaScript documentation (eventually at [DevEdge]) or in the ECMAScript Language Specification that it will be the decompiled source code. In fact, the Specification explicitly says that the value is implementation-dependent ([ES], §15.3.4.2). That implementation-dependence can be observed when comparing the return values of various “JavaScript”s (ES implementations that have “JavaScript” in their name), showing that they are indeed different implementations of that Specification. For example, some “JavaScript”s return a string value containing the original comments while others do not. We have discussed this here before. Finally, the term “function” appears to be underdefined in that statement. The above does not apply to all functions in the sense of callable objects, but only to *user-defined* functions as defined in the first paragraph of this section. As an example, the built-in object referred to by the initial value of “Object.prototype.toString” is a Function instance but it violates/extends the Specification as its toString() method returns "function toString() {\n [native code]\n}" which (evaluated) cannot be produced by /FunctionDeclaration/: “[native code]” is not a valid expression. > A definitions of the meaning of a term is not »true« or > »false«, rather it is »agreed upon« or »not agreed upon« > within a certain group of parties. For reasons that should be obvious by now, I cannot agree with the cited statement as a whole; in fact, I find that I can fully agree (in the sense that I would sign it) only with the first phrase of its first sentence. __________ [0] , “Help improve MDN” [DevEdge] [DOMCore] [ES] [ES3] [MDN] -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not Cc: me. / Bitte keine Kopien per E-Mail.