New Host Object Primer
in [JavaScript]
|
Prev: FAQ Topic - Internationalisation and Multinationalisation in javascript. (2010-03-23)
Next: buy online Diazepam, purchase Diazepamwithout a prescription, buy Diazepamon line no prescription
From: Garrett Smith on 23 Mar 2010 19:19 kangax wrote: > On 3/23/10 6:00 PM, David Mark wrote: >> kangax wrote: >>> On 3/23/10 12:52 PM, David Mark wrote: >>>> I have posted a new primer related to host objects and feature >>>> detection/testing. [...] > Yeah, I should report it to them. The fact that Opera bug tracker is not > open is annoying (I have no idea what's going on with the bugs I filed > in the past). > "Signs point to yes" (source: magic 8 ball). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 23 Mar 2010 19:32 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> >>> Garrett Smith wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i [...] >> But AISB the `!!' does not really save anything as in a boolean context the >> return value would be subject to type conversion anyway. > > That's true. But I prefer to have the function return booleans only. > Having gthe function return boolean provides clear expectations to the caller. WIth an "is" method, the caller should be able to expect a boolean value. This expectation could be clearly defined by a unit test. I might write it like this: "testIsHostMethod - contains" : function(){ var actualResult = isHostMethod(document.body.contains); Assert.isTrue(actualResult); } That isHostMethod returning something other than false would end up failing that test. By always returning boolean value, the expectation is simpler. >>>> Caveats: >>>> Object `o` could be callable and falsish, such as nonstandard callable >>>> "document.all". >> Is there a good reason for document.all(...) instead of document.all[...]? >> If not, that fact is largely irrelevant. > > I missed that that second part was mentioned. I already mentioned about > the sometimes callable objects in the explanation and documentation. > Don't request an opinion from isHostMethod on those. > I was not suggesting a workaround for the document.all anomaly. The use of document.all should be abstained from. >> >>>> Object `o` could be the `item` method, for which typeof will result >>>> "string" in IE. This would result in isHostMethod returning false. >>> Yes, I should add both of those stipulations to the docs and this >>> example. >> That argument only makes sense if _o[m]_ refers to the item() method of >> NodeList or HTMLCollection implementations. Then again, is there a good >> reason to call o.item(i) instead of accessing o[i]? If not, that fact is >> largely irrelevant. >> > > Right. It is odd that the one exception to an otherwise golden rule is > something you would/should never need anyway. Still, it's an > interesting caveat and I think I will mention it. I can't think of a good reason for preferring item() over []. I recall testing Firefox up to 1.5 and [] was faster than item() there. Browsers nowadays are so fast that that difference (which may not exist any longer) would hardly matter much. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 23 Mar 2010 20:46 kangax wrote: > On 3/23/10 6:00 PM, David Mark wrote: >> kangax wrote: >>> On 3/23/10 12:52 PM, David Mark wrote: >>>> I have posted a new primer related to host objects and feature >>>> detection/testing. >>>> >>>> http://www.cinsoft.net/host.html >>> >>> Is there a reason `isHostObjectProperty` is not called `isHostProperty` >>> (to be consistent with `isHostMethod`)? >> >> The "Object" goes with "Property", not the "Host" part. > > I understand that :) But what does "Property" clarify there? What's > wrong with having `isHostMethod` and `isHostProperty` � where first one > is for testing anything that's intended to be called (i.e. method), and > latter � for anything that won't be called (i.e. property). Because it only tests for object properties (i.e. not booleans, strings, numbers, etc.) > > [...] > >>> >>> Finally, it might be worth mentioning that `isEventSupported` could (and >>> _does_, as any other inference) return false positives; from those I >>> know about � `window`'s "error" in Chrome (present but "defunct"), and >>> "contextmenu" in Opera 10.50 (even when corresponding option is off in >>> settings!). >> >> It is only meant to be used with elements (which I should stipulate of >> course). As for "contextmenu", I never considered that a false >> positive. The event is supported, but like many things in browsers, the >> user has the ability to get in the way. But from your wording, it >> sounds as if there is a bug in Opera 10.5 that should be noted (and >> reported). > > Yeah, I should report it to them. The fact that Opera bug tracker is not > open is annoying (I have no idea what's going on with the bugs I filed > in the past). > Yeah, I hope they get that fixed. ISTM, their preferences dialog sometimes gets out of whack with the reality of the browser window. Still, I like it and have taken to using it as my primary browser.
From: David Mark on 23 Mar 2010 20:48 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>> >>>>> I have posted a new primer related to host objects and feature >>>>> detection/testing. >>> [...] >>> >>>> ISTM the RegExp is borken: >>>> >>>> var reFeaturedMethod = new RegExp('^function|object$', 'i'); >>>> >>>> It matches case-insensitive either "function" at the begin of input or >>>> "object" at the end, when it should match case-insensitive an input >>>> that is either "function" or "object": >>>> >>>> var reFeaturedMethod = new RegExp('^(function|object)$', 'i'); >>>> >>> A Literal would be shorter and would stay cached: >>> >>> /^(?:func|obj)/; >> >> I fail to see how that is the same thing, but the non-capturing bit is a >> good idea. >> > It is not the same thing. > > Either would do the job as well as: > /^(?:function|object)$/; I don't want to let anything through that is "func" or "obj". That's a slippery slope (i.e. why not just test for "fu" and "ob"). > > Being case-insensitive is pointless, though. I'd ditch the 'i' flag > either way. I suppose. > >> As for caching, I don't see how it makes any difference as I create the >> RegExp object once. >> > > The difference would be when the object is created. Either at runtime > (as with constructor) or during lexical scan for regexp literal. Right, but I didn't understand what was meant by "caching" as it is a one-shot deal in either case.
From: David Mark on 23 Mar 2010 21:03
Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> I have posted a new primer related to host objects and feature >>>> detection/testing. >>>> >>>> http://www.cinsoft.net/host.html >>>> >>> | The isHostObjectProperty function tests if the specified host object >>> | property references an object that is safe to evaluate. >>> >>> The term "evaluate" is non-standard terminology. What do you mean? >> >> Anything along the lines of type conversion, assigning a reference to a >> variable, etc. What would you call it? > > I like to see the standard terminology to describe the problems. Yes, and that would be what in this case? I mean a single word to replace evaluate. I realized when I wrote it it wasn't technically specified, but couldn't come up with a better word. > I mentioned a few of the problems with host objects here: > > http://jibbering.com/faq/notes/code-guidelines/#hostObjects Yes, and speaking of the FAQ:- http://www.jibbering.com/faq/#onlineResources ....needs section for browser scripting resources (e.g. mine, Kangax' blog, etc.) And:- http://www.jibbering.com/faq/faq_notes/contributors.html ....needs my name added. At the very least, the confirm issue I fixed:- http://www.jibbering.com/faq/#changeBrowserDialog > > Posted inline, for convenience: > | Host Objects: > | > | * Operators: > | o Do not use delete operator with host object (IE Errors) Sound, but I would ditch the parenthetical. Could happen to any browser. > | o Do not add any expando properties (unselectable is safe) What is this one's aside about? > | o Host objects that error upon [[Get]] access are often ActiveX > | objects. These include, but are not limited to: Host object _properties_ that throw errors on [[Get]] (a term that is too subterranean for my primers) often indicate that the containing object is an ActiveX implementation. All such method properties do it. > | + Disconnected nodes whose parentNode is not an element > | (node.offsetParent) In some cases, all properties of element nodes go AWOL ("unknown" typeof results). IIRC, that happens when they are orphaned by an innerHTML replacement. > | + XMLHttpRequest methods (open, send, etc). And its ActiveX equivalents. > | + filters: elem.filters.alpha, elem.style.filters.alpha, etc. The filters object is implemented with ActiveX, so its properties are suspect. > | + document.styleSheets[99999] - Error from [[Get]] for a > | nonexistent numeric property of a styleSheets collection. That one may not be due to ActiveX, but just an allowable exception for an out of bounds request. > | + link.href for nntp: links in IE. Yes, the Stockton href incident. That one was truly unexpected (and likely a bug) as how else are you to get the href value. (!) > | + NodeList in Safari 2 - do not attempt access a nonexistent > | property (e.g. document.childNodes.slice). That's an odd one. Likely also a bug. > | > | * Type conversion > | [[ToString]] > | Perform string conversion by starting concatenation with a string > | value. See Newsgroup message explanation. > <URL: > http://groups.google.bg/group/comp.lang.javascript/msg/1528f612e31f09fe > I don't see how the explanation relates to host objects, which don't have to follow the specs at all. |