Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <15740262.UMIpHFasVP@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 24 Oct 2012 01:21:13 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1538954.egObkdgl4n@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 66 NNTP-Posting-Date: 24 Oct 2012 02:21:13 CEST NNTP-Posting-Host: c3bb1b53.newsspool3.arcor-online.net X-Trace: DXC=f^ghemQiFUIk:C4l9A;OcOMcF=Q^Z^V3H4Fo<]lROoRA8kFK@JjkNj3FBJ;I[YHULT7b]CO X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:16824 Patricia Shanahan wrote: > Thomas 'PointedEars' Lahn wrote: >> Patricia Shanahan wrote: >>> It is perhaps natural because I have been programming so long in >>> more strongly typed languages. >>> >>> Is it a problem? >> >> With that "much" information, I have to say yes. > > The good news is that I do understand the problem of trying to program > in language X as though it were language Y. People who do that end up > programming in a very unsatisfactory language containing only the > features that are in common to the two languages, and work the same way > in both of them. ACK. >>> On the one hand, it makes for very organized code, with a lot of >>> opportunities for adding type-checking assertions, generally a good >>> thing. On the other hand, I may be missing out on opportunities to make >>> my code simpler and a better fit for the language. >>> >>> Is it enough to be aware of the dynamic aspects of the language, and be >>> prepared to use them when strong typing gets in the way? >> >> (see above) >> >> No. (However, contrary to common misconception, there are no "untyped >> variables". Implementations of ECMAScript Ed. 1 to 3, 5, and 5.1 are >> dynamically and weakly typed, not untyped. Uninitialized variables and >> trailing parameters for which no argument has been passed, hold the >> `undefined' value, the sole value of the Undefined type.) > > As I understand the issue, a variable always has a type, but that type > can change on assignment. Similarly, the type of a formal parameter is > determined by the type of the actual parameter in the call, or, as you > say, the Undefined type if the call did not supply an actual parameter. Correct. "Dynamically typed" (as opposed to "statically typed") means that the type of an expression is determined on runtime, not compile time. "Weakly typed" (as opposed to "strongly typed") means implicit type conversion of a value if an operation requires it. The latter is a very powerful feature; but keep in mind that power corrupts ;-) > This is obviously significantly different from having a type that is > fixed at declaration, and I need to wrap my brain around the implications. One implication is that you have optional parameters for free. You can access the `arguments.length' property to find out how many arguments have been passed, and access them with arguments[n] (where n is a 0-based index). Another is that overloading is only as useful as one is able to differentiate between the different argument types and values (so for example, because host objects do not need to exhibit exactly specified behavior, you should not require references to them as parameters of overloaded method. Overloading and host objects do not mix. Many popular libraries make that mistake and are inherently unreliable as a a result.) PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from (404-comp.)