What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: David Mark on 14 Nov 2009 22:48 On Nov 14, 10:17 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > Thomas 'PointedEars' Lahn wrote: > > David Mark wrote: > <snip> > >> How about this one:- > > >> if (typeof xyz == 'array' || xyz instanceof Array) { > >> ... > >> } > > >> First test is _never_ true in an ECMAScript implementation. > > > That is not quite correct. The first test could result in `true' > > in a conforming implementation of ECMAScript if `xyz' referred to > > a host object. But I doubt the person writing it was aware of > > that or even intended to meet the case. > > <snip> > > That "could result in 'true'" is very much a theoretical possibility; a > host object may result in any string when - typeof - is applied to it, > but it is extremely rare that they do result in anything that is not > already in the ECMAScript list, and the exception ('unknown' in IE when > testing ActiveX objects, methods and properties) is literally the only > one that I have ever encountered, or heard tell off. That's be > > Personally, I don't believe that there has ever been a browser > environment in which any object (host or otherwise) resulted in 'array' > when - typeof - was applied to it. I think that is formulation (and the > many similar - typeof - tests) is just another of those mystical > inactions that start out as someone's mistake and propagate precisely > because they are essentially harmless (the 'array' result never happens > and so the code guarded by it is either unconditionally executed or not > executed). > > That is probably the measure of an 'engineer' in this context; an > engineer would want to identify and eliminate the mystical incantations > from what they were doing. > It seems some are unsure how to identify mystical decision decisions. There is this "show me" attitude that seems to reduce programming to observation. The programmer role is reduced to one who can observe patterns, rather than one who can understand abstractions. And, as mentioned, this is one bug that will never "show" its face (and is actually just an ineffectual waste of space and a telltale sign of the author's spot on the JS learning curve). But this attitude becomes dangerous on more critical design decisions. I've heard talk of a script loading mechanism that will rely solely on the non-standard onreadystatechange and onload properties of created SCRIPT elements. The plan is to inject SCRIPT elements directly into the HTML element and then rely on the non- standard events to fire and put everything in order. ISTM that relying on observations of these two hacks working together in a limited set of present environments is folly. Furthermore, investigating its viability by searching for an environment that fails is a waste of time (i.e. what does it prove if one can't be found?) and a backwards approach to browser scripting. I think an engineer would dismiss the fantasy scenario(s) out of hand and think about better alternatives with at least some basis in present reality and/or tradition in history. Can you imagine if C++ - for example - were written like this? It would actually be easier in some respects. Trying to script browsers by feel seems like Mission Impossible by comparison (and perhaps that's why so many involved with JS consider it impossible).
From: Richard Cornford on 14 Nov 2009 23:36 David Mark wrote: > On Nov 14, 10:17 pm, Richard Cornford wrote: ><snip> >> That is probably the measure of an 'engineer' in this context; >> an engineer would want to identify and eliminate the mystical >> incantations from what they were doing. >> > > It seems some are unsure how to identify mystical decision > decisions. There is this "show me" attitude that seems to > reduce programming to observation. But in this case that can easily be turned around, and the question "show me the browser environment in which any object results in 'array' when a - typeof - operation is applied to it". After all, you can show them the environments where objects result in 'undefined' and methods in 'string' (IE <= 7, - item - methods of all 'collection' objects). It seems reasonable that if you know the oddities that do exist then your not knowing of this oddity suggest that is does not exist. > The programmer role is reduced to one who can observe > patterns, rather than one who can understand abstractions. I am noticing a resurgence in object inference testing, it the mistaken belief that it represents feature detection. Object inference is probably one of the better examples of decisions based on observing a pattern. The ubiquitous example being:- if(document.images){ image = new Image(); img.src = 'some URL' } - where the inference is that an environment in which - document.images - exists will be an environment in which the - Image - constructor exists. The code works fine, and I am unaware of any environment where - document.images - exists and the - Image - constructor odes not, or where the - Image - constructor exists and - document.images - does not. So the observed relationship (*probably*) will not be empirically contradicted. On the other hand, the feature-testing alternative where the subject of the test is the - Image - constructor should be obviously superior to anyone rational. The relationship between the existence of - document.images - and existence of the - Image - constructor is coincidental, even if it does hold universally, but the relationship between the existence of the - Image - and the existence of the - Image - constructor is direct and can be expected to hold universally for logical reasons. The question is not 'what is wrong with the object inference version if it has never been shown to fail?', but rather 'what is wrong with the more logical feature detection version that would suggest using the object inference version in its place?. > And, as mentioned, this is one bug that will never "show" > its face (and is actually just an ineffectual waste of > space and a telltale sign of the author's spot on the JS > learning curve). Yes, it is a mystical incantation. > But this attitude becomes dangerous on more critical design > decisions. I've heard talk of a script loading mechanism > that will rely solely on the non-standard onreadystatechange > and onload properties of created SCRIPT elements. The plan > is to inject SCRIPT elements directly into the HTML element > and then rely on the non-standard events to fire and put > everything in order. ISTM that relying on observations of > these two hacks working together in a limited set of present > environments is folly. Yes, it is precisely that sort of thing that places arbitrary constraints on the set of supported browsers without there being any real need to be doing so. > Furthermore, investigating its viability by searching for an > environment that fails is a waste of time (i.e. what does it > prove if one can't be found?) It proves that another browser is going to be labelled "C Grade" (so it is the user's fault if the code does not work on their browser). ;-) > and a backwards approach to browser scripting. I think an > engineer would dismiss the fantasy scenario(s) out of hand > and think about better alternatives with at least some basis > in present reality and/or tradition in history. > > Can you imagine if C++ - for example - were written like this? > It would actually be easier in some respects. Trying to script > browsers by feel seems like Mission Impossible by comparison > (and perhaps that's why so many involved with JS consider it > impossible). Whether software authoring is engineering or not has always been disputed. It would be nice to think that things could be done on a more (or increasingly) rational basis, but a lot of experience of 'average' web developers tends to justify my natural cynicism. Richard.
From: Richard Cornford on 14 Nov 2009 23:55 Richard Cornford wrote: > ... After all, you can show them the environments where > objects result in 'undefined'... That 'undefined' should have been 'unknown', but you probably figured that out already. Richard.
From: David Mark on 15 Nov 2009 00:08 On Nov 14, 11:55 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > Richard Cornford wrote: > > ... After all, you can show them the environments where > > objects result in 'undefined'... > > That 'undefined' should have been 'unknown', but you probably figured > that out already. > Actually, I thought you meant document.all in FF quirks mode. ;)
From: Richard Cornford on 15 Nov 2009 00:20
David Mark wrote: > On Nov 14, 11:55 pm, Richard Cornford wrote: >> Richard Cornford wrote: >>> ... After all, you can show them the environments where >>> objects result in 'undefined'... >> >> That 'undefined' should have been 'unknown', but you probably >> figured that out already. > > Actually, I thought you meant document.all in FF quirks mode. ;) Fair enough, that will do as your third example of a host object - typeof - oddity that can be stated. (Which reminds me, there is (or was, as it has been criticised) something in Safari that claims to be 'undefined' even though it can be shown to exist (be an object or function). I don't recall the detail, but I think Garrett may be in a position to say what it is (without looking it up in the ES 4/3.1 mailing list archives.)) Richard. |