Identifier like "_", "$", etc.
in [JavaScript]
|
Prev: A practical exercise: fighting maskons
Next: FAQ Topic - How do I get a jsp/php variable into client-side javascript? (2009-11-10)
From: optimistx on 11 Nov 2009 05:23 David Mark wrote: .... > And don't discount the impact of function calls on performance, > especially when manipulating the DOM. Their presence (or the lack > thereof) is often critical to performance. Would you like to give a couple of examples, which might oftern happen in real life programming ?
From: Richard Cornford on 11 Nov 2009 11:10 kangax wrote: > Garrett Smith wrote: <snip> >> That's odd. Seems in Tracemonkey, a RegExp is callable without >> implementing [[Call]], or ? A bug in there syntax extension, due >> to internal typechecking for RegExp, as: >> typeof /a/ > > Yes, from what I remember, Mozilla makes regex objects callable > without actually giving them [[Call]]. That would be very clear violation of ECMA 262, 3rd Ed., where Section 11.2.3 (Function Calls) features the words "If Result(3) does not implement the internal [[Call]] method , throw a TypeError exception" as step 5 in its algorithm. That is, in ES3 terms, if it does not have a [[Call]] method it cannot be called, and so if it can be called it _must_ have a [[Call]] method (or at least that is the required behaviour, so the ability to call something has direct implications for all other situations where the existence of a [[Call]] method is relevant). The specifics have moved around in ES5, but the internal IsCallable function still boils down to 'does the object have a [[Call]] method', so nothing has really changed. On e of the main things that has dogged the - isFunction - question over its very long history is that very few people have been willing to state what 'being a function' represents. If you can give a clear definition of what 'being a function' is then you are probably in a position to either design and effective - isFunction - method, or to declare the determination untestable and so give up the attempt. Instead we see lots of example of - isFunction - method that do something, get criticised for the inconsistencies in that something, and then get changed so they do something else, with nobody ever stating what the definition of 'Function' is that their - isFunction - is supposed to be testing. Personally, I like a definition of 'function' that goes; "if you can call it then it is a function". It is a definition that rules out the viability of an - isFunction - test function (you would have to call the object to see if it is callable, and that might have side-effects), but it is also a very simple/obvious definition that does not introduce issues of itself. A (one of the many) bugbears of - isFunction - Firefox's response to:- var x = document.createElement('OBJECT'); - which, when tested with - typeof - returns 'function'. This is seen as incorrect, e.g.:- <URL: http://jsninja.com/Functions#Function_Type > The idea being that - createElement - should return an object implementing the Element (and by implication Node) interfaces from the W3C DOM (which is true), and that those object should not be callable (which is an assertion that has no technical basis[1]), and therefore that the - typeof - operation applied to such an object should not result in 'function'. [1] The W3C DOM is defined in terms of interfaces; sets of properties and methods that object implementing those interfaces must possess (in some practical sense). Neither ECMAScript, the W3C DOM specs nor the ECMAScript bindings for the DOM interfaces place any restrictions on the nature of the objects implementing an interface, and as ECMAScript functions are objects there is absolutely no reason for any object implementing a W3C DOM interface not to be an ECMAScript function. Thus Element and Node interface implementing objects could be functions (as could objects implementing HTMLCollection, NodeList or NamedNodeMap), the decision is left up to the creators of the DOM providing host. If you try to call the Firefox OBJECT element an exception is thrown, but it is not the "x is not a function" exception that would be thrown if the OBJECT element were not callable. The implication being that the element is callable and the exception that is thrown is thrown within the call. So, by a very reasonable definition of 'being a function' the Firefox OBJECT element is a function (it can be called), and so its resulting in 'function' when - typeof - is applied is actually a very reasonable indicator of a truth about the nature of the object in question. The point being that there is no technical reason to expect to be able to discriminate between objects implementing the Element interface (or any other DOM specified interface) and an ECMAScript function. This immediately brings into question the worth of having an - isFunction - test function in the first place, especially in relation to its common use in attempting to emulate 'method overloading' in ECMAScript. (In fact, it brings into question the general viability of emulating 'method overloading' in javascript, when you can only make superficial discriminations between the types of values that are the arguments to a function call). The relevance for a regular expression's having, or not having, a [[Call] method? If you cannot expect to be able to discriminate a DOM node from a function not finding it easy to discrimination a regular expression from a function (using - typeof - (as the specific discrimination by duck-typing the respective object's methods/properties is viable)) is not making things any worse. > In WebKit, on the other hand, regex do have [[Call]] and so typeof > returns "function", as per specs (native object + has [[Call]] == > "function"). <snip> >> Many won't read the documentation of others (including pertinent >> specifications, as witnessed recently on this NG). Developers >> often skip right to the "what does it do" (functions, examples, >> or tests). I recall one of my colleagues being amused to find me reading the SOAP/WSDL specifications prior to writing a SOAP client for our web applications. > It's no surprise that ES3 specs are hard to follow and full of > ambiguities. A year ago, the only way I could understand certain > things in specs is with the help of wonderful explanations by > Cornford and Lasse in the archives (on related subjects). An interesting mix of formality and informality in your choice of identifiers there. :) > Your last question on es-discuss proves how hard it could be to > discern specs correctly. > > ES5, fortunately, takes care of some of these uncertainties. <snip> The ES5 spec may remove some ambiguities, but it is not going to prove any easier for newcomers to 'get into', at least in part becasue it introduces many new internal objects/functions that will not ease the need to continually be going back and forth cross-refencing things. Richard.
From: Peter Michaux on 11 Nov 2009 12:06 On Nov 9, 5:02 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Peter Michaux wrote: > > On Nov 9, 2:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > >> | 7.6 Identifiers > >> | This standard specifies one departure from the grammar given in the > >> Unicode standard: The dollar sign ($) and the > >> | underscore (_) are permitted anywhere in an identifier. The dollar > >> sign is intended for use only in mechanically > >> | generated code. > > I believe this statement is gone from the proposed ECMAScript 5 and if so > > I think it is good they removed it. > > Well, I for one do not want to see code like the following spreading around: > > <?php > $bar = 'baz'; > $foo = 'bar'; > echo <<<JS > \$foo.\$ = '{$$foo}'; > JS; > ?> > > Do you? No. I think that I would not have allowed '$' to be part of identifier in the first place. Peter
From: Thomas 'PointedEars' Lahn on 11 Nov 2009 12:40 Peter Michaux wrote: > Thomas 'PointedEars' Lahn wrote: >> Peter Michaux wrote: >> > On Nov 9, 2:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: >> >> | 7.6 Identifiers >> >> | This standard specifies one departure from the grammar given in the >> >> | Unicode standard: The dollar sign ($) and the underscore (_) are >> >> | permitted anywhere in an identifier. The dollar sign is intended for >> >> | use only in mechanically generated code. >> > >> > I believe this statement is gone from the proposed ECMAScript 5 and if >> > so I think it is good they removed it. >> >> Well, I for one do not want to see code like the following spreading >> around: >> >> <?php >> $bar = 'baz'; >> $foo = 'bar'; >> echo <<<JS >> \$foo.\$ = '{$$foo}'; >> JS; >> ?> >> >> Do you? > > No. I think that I would not have allowed '$' to be part of identifier > in the first place. Then I do not understand your opinion above. A recommendation against, as it is in Edition 3, is a step in the right direction in that sense; a missing recommendation against, as it could be in Edition 5, is not. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 11 Nov 2009 12:46
On Nov 11, 5:23 am, "optimistx" <optimi...(a)hotmail.com> wrote: > David Mark wrote: > > ...> And don't discount the impact of function calls on performance, > > especially when manipulating the DOM. Their presence (or the lack > > thereof) is often critical to performance. > > Would you like to give a couple of examples, which might oftern happen > in real life programming ? Just manipulate the DOM in a loop with and without function calls. And understand that the browser waits until an execution context is exited before re-rendering the document. As documents get larger and more complex, the problem becomes more apparent. |