Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.mixmin.net!feeder.erje.net!news.internetdienste.de!news.tu-darmstadt.de!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1931062.YjaipZm5s4@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 21 Dec 2011 13:42:31 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: Is this the only way to unit-test an events abstraction? Newsgroups: comp.lang.javascript References: <6567149.685.1324401412063.JavaMail.geo-discussion-forums@yqbo42> <1658658.tIHn9WeWv6@PointedEars.de> <23062766.184.1324459638434.JavaMail.geo-discussion-forums@vbmi7> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 120 NNTP-Posting-Date: 21 Dec 2011 13:42:32 CET NNTP-Posting-Host: 14c2093d.newsspool2.arcor-online.net X-Trace: DXC==fR_CIgFOZ6RadXUBHgFh3A9EHlD;3Yc24Fo<]lROoR18kF X-Complaints-To: usenet-abuse@arcor.de Xref: x330-a1.tempe.blueboxinc.net comp.lang.javascript:9488 storm.mark@gmail.com wrote: > Thomas 'PointedEars' Lahn wrote: ^^^^^ ^^^^^ Argh. >> Please put your real name there. > Sorry about that, I had put my name at the bottom so people knew who they > were talking to. It is customary to put your *name* in the *sender* information (From header field, with exceptions) as well (you may sign your postings at the bottom in any way you wish). Internet is about cables; Usenet is about people. >> Bottom line: Eschew attachEvent(). > > So the reason why (in your provided example script) you do not utilise > attachEvent and fall back to proprietary event-handler is because of the > lack of event execution order (in your fallback I believe you're storing > up the listener functions and execute them in the relevant order and pass > through a normalised event object) Correct. >> Further, you should _not_ assume that because the object referred to by >> `this' (the global object) exposes the method, all objects must expose >> it, ^^^^^^ >> and that it must be working for all event types. The same applies for >> the ^^^^^^ >> assumption of the opposite. The more reliable approach, if slightly less Argh. >> efficient, is to use the approach that appears to be working when the >> event was created. > > So (as I can see in your example code) instead of doing what I am, which > is to check for addEventListener on the window object and then rewrite the > adding function, you suggest doing the check every time for whatever > object the adding of an event is called on (even though it's slightly less > efficient). Correct. >> That is partially correct. `typeof' is an *operator*, it does not >> *return* ^^^^^^^^^^^ >> anything. "unknown" may be the *result* of a `typeof' operation in *all* >> DOM implementations; there is no limit as to in which implementations it >> may be the result, or up to which MSHTML version it can be returned. >> ActiveX/COM has little to do with it; the point is those are *host* >> objects, and their `typeof' operation is allowed, by Specification, to >> result in any ^^^^^^^^^^^^^^^^ Argh. >> string (loosely speaking). See ECMA-262 Ed. 3 and 5.1, sections 11.4.3, >> for details. > > OK, thanks for clarifying the 'terminology' of return and result (looking > at it now I can see how my wording is confusing). I'll also be wary of > relying on 'unknown' as a way of detecting a host object/method Emphasis on "loosely speaking" here. While in theory it may be any value, for the relevant objects there has not been observed a non-specified value other than "unknown" (CMIIW). >> [JFTR: I am partially responsible for the way David's isHostMethod() >> [looks ^^^^^^^^^ Argh. >> today, for IIRC I have started this is…Method() business with isMethod() >> years ago (search the archives). Curiously enough, I have recently >> (JSX@234) found it useful to "split" jsx.object.isMethod() so that there >> would be jsx.object.isNativeMethod() as well, as David did before, to >> tell user-defined event listeners from unsuitable objects apart in >> event.js.] > > I'll search the archives here to see if I can locate your isMethod and > review how that works The original isMethod() function is only of historical value now. You should look into the current jsx.object.isMethod() and jsx.object.isNativeMethod() methods in JSX:object.js instead (same SVN repository, in /trunk/). >> If you mean feature-tests at runtime: No. For you would need to create >> an event object as well, which firstly cannot be done everywhere, >> secondly would only create an event of one of the numerous event types if >> it worked, ^^^^^^^^^^^^^ Argh. >> and thirdly you would require feature detection for that as well. So >> that can only reduce your chances of getting a useful event library (0.5³ >> = 0.125). > I'll review your provided script and see how you've gone about > implementing your events library then so I make sure I'm understanding all > the concepts correctly. Always have more than one source of information. Your postings become easier readable if you add an empty line after quotations (and do not use Google Groups for posting, but a good local newsreader application, like Thunderbird/Icedove or KNode, instead). PointedEars -- > If you get a bunch of authors […] that state the same "best practices" > in any programming language, then you can bet who is wrong or right... Not with javascript. Nonsense propagates like wildfire in this field. -- Richard Cornford, comp.lang.javascript, 2011-11-14