What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: Asen Bozhilov on 15 Nov 2009 08:32 Richard Cornford wrote: > .... and methods in > 'string' (IE <= 7, - item - methods of all 'collection' objects). window.alert(typeof window.Image.create); //string window.alert(typeof window.Option.create); //string
From: Richard Cornford on 15 Nov 2009 10:34 Asen Bozhilov wrote: > Richard Cornford wrote: > >> .... and methods in >> 'string' (IE <= 7, - item - methods of all 'collection' objects). > > window.alert(typeof window.Image.create); //string > window.alert(typeof window.Option.create); //string For that to be significant you have to point out that the - create - properties of these objects can be called, despite their appearing to be string primitives in most regards. It turns out that the apparent fix for the item methods on IE 8 is dependent on the 'mode' triggered by the DOCTYPE. I.E.:- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title></title> </head> <body> <pre> <script type="text/javascript"> var x = window.Image.create(); document.write( '(typeof x) -> '+ (typeof x)+'\n'+ '(\'\' + c) -> '+ ('' + x) ) document.write( '\n\n(typeof window.Image.create) -> '+ (typeof window.Image.create)+'\n'+ '(window.Image.create instanceof String) -> '+ (window.Image.create instanceof String)+'\n'+ '(Object(window.Image.create) instanceof String) -> '+ (Object(window.Image.create) instanceof String)+'\n'+ '(typeof Object(window.Image.create)) -> '+ (typeof Object(window.Image.create))+'\n'+ '(Object(window.Image.create) == window.Image.create) -> '+ (Object(window.Image.create) == window.Image.create)+'\n'+ '(Object(window.Image.create) === window.Image.create) -> '+ (Object(window.Image.create) === window.Image.create)+'\n'+ '\'[object HTMLImageElement]\' === window.Image.create) -> '+ ('[object HTMLImageElement]' === window.Image.create) ) document.write( '\n\n(typeof document.forms.item) -> '+ (typeof document.forms.item)+'\n'+ '(document.forms.item instanceof String) -> '+ (document.forms.item instanceof String)+'\n'+ '(Object(document.forms.item) instanceof String) -> '+ (Object(document.forms.item) instanceof String)+'\n'+ '(typeof Object(document.forms.item)) -> '+ (typeof Object(document.forms.item))+'\n'+ '(Object(document.forms.item) == document.forms.item) -> '+ (Object(document.forms.item) == document.forms.item)+'\n'+ '(Object(document.forms.item) === document.forms.item) -> '+ (Object(document.forms.item) === document.forms.item)+'\n'+ '\'[object]\' === document.forms.item) -> '+ ('[object]' === document.forms.item) ) </script> </pre> </body> </html> - outputs:- (typeof x) -> object ('' + x) -> [object HTMLImageElement] (typeof window.Image.create) -> string (window.Image.create instanceof String) -> false (Object(window.Image.create) instanceof String) -> true (typeof Object(window.Image.create)) -> object (Object(window.Image.create) == window.Image.create) -> true (Object(window.Image.create) === window.Image.create) -> false '[object HTMLImageElement]' === window.Image.create) -> true (typeof document.forms.item) -> object (document.forms.item instanceof String) -> false (Object(document.forms.item) instanceof String) -> false (typeof Object(document.forms.item)) -> object (Object(document.forms.item) == document.forms.item) -> true (Object(document.forms.item) === document.forms.item) -> true '[object]' === document.forms.item) -> false - but if you remove the DOCTYPE the final section for - document.forms.item - changes to:- (typeof document.forms.item) -> string (document.forms.item instanceof String) -> false (Object(document.forms.item) instanceof String) -> true (typeof Object(document.forms.item)) -> object (Object(document.forms.item) == document.forms.item) -> true (Object(document.forms.item) === document.forms.item) -> false '[object]' === document.forms.item) -> true That is, apparently in 'quirks' mode the - item - method reverts to its previous nature. (There is an apparent inference test for IE 8 'standards' mode in there). Richard.
From: Richard Cornford on 15 Nov 2009 10:34 The Natural Philosopher wrote: > RobG wrote: > >> Empirical evidence is used to develop and support a theory, however >> the theory itself must have a scientific basis - that >> is, it must have a rational explanation that will predict >> behaviour in similar circumstances. Simply observing that >> something happens is just an observation of a fact, an >> experiment. Being able to repeat an experiment and achieve >> the same outcome every time doesn't prove anything other >> than that the experiment is repeatable, it doesn't provide >> any explanation of why the experiment "works", nor predict >> the likely outcome if the parameters are changed, nor provide >> any bounds within which it "works" or "fails". > > However most of science is, in the *final* analysis, precisely > what you describe. I don't think so. > a set of propositions that may (or may not!) reflect an > underlying reality, whose predictions have failed to ever > be falsified by experiment, and whose propositions CAN in > principle be falsified. Being 'falsifiable in principle' means being in a position to make predictions such that those predictions can be empirically tested in a way that could produce result that would contradict theory that produced the perditions. > And which actually add some value that competing theories > do not. > > Cf Kuhn, Popper, Instrumentalism, et al. > >> Without the explanation, there is no theory. There is no >> application of scientific knowledge, no understanding of >> why the result occurs. It is no more than faith - it's >> always worked before in their limited experience, therefore >> they expect it to always work. Anyone who performs work using >> such methods should be categorised as a trades person. They >> are certainly not professionals applying scientific >> theories or methods. They are not engineers. > > :-) sadly, there are no final explanations for anything. There may be final explanations, what there isn't is any way of recognising them as final if/when they do exist. > will the sun rise tomorrow? Can't say really. It always > HAS...whether that's because it obeys certain immutable > laws of physics that we BELIEVE to be universal true (nay > DEFINE to be universally true) Even if the sun does obey immutable laws of physics that would be no guarantee that it will "rise tomorrow" (even if the assumption that it does will significantly influence out judgements about whether it is likely to rise tomorrow). > or whether its because the Ngongobongo tribe absolutely > do a special tribal dance every sunset to make sure it > does, is a very moot point. Not really. If you credit the mystical explanation, you risk squandering resources indefinitely preserving the tribe that has the power over life and death, and facilitating their dancing activates. > Oh, and an explanation is not a theory, and certainly not a > scientific theory, The assertion is the other way around; that a scientific theory will be an explanation (of something). > nor is a scientific theory an explanation. Yes they are. > It is if you like, the expression of the result of a lot of > experimental data in terms of an algorithm. It is entirely feasible for an explanation to be made up off the top of someone's head on the spot, no empirical data necessary. > In the same way that the reality of our perceptions is a compressed > representation of all the salient features > of all the data we are subjected to. > > E=mc^2 is a shorthand algorithm for calculating mass-energy > relationships. E=mc^2 isn't really an explanation, it is more part of an explanation. > That is borne out by observation. The point of being born out by observations in that case is that the theory predicted that the observations would be made before some of them had been made (and before some of them could be made, due to technological limitations). Relativity predicts gravitational lensing (and predicts the observable distortion that results), then the observation is made during a subsequent eclipse and the observed results correspond to the predicted results. Not 'proof' of the theory but certainly an opportunity for the theory to be shot down in flames if it were wrong. > I am not sure it explains anything at all. It does explain why matter/anti-matter annihilation (where all mass is transformed to energy) can be expected to release so much energy (and indeed, how much energy for any given mass). > Not in any fundamental way. Its just the expression of a constancy of > relationship between certain > elements of a world we have defined in certain precise terms. > > 'Because God wills it' is the ultimately irrefutable explanation > for everything. That doesn't make it a scientific theory in > any sense. That would be because a science/metaphysics demarcation requires refutability of the things that are science. > A professional engineer is one who makes his living out of > designing engines. That becomes a very specific definition of 'engineer'. (I bet the majority of the worlds engineers have never designed anything that would generally be perceived as an 'engine' by the majority of the population of the plant.) > HOW he does it, is really no part of what he is. Even if the definition is no more than 'making a living by designing engines' then certain things do follow. If the engines designed don't actually work (don't run at all, don't last for a reasonable time when run, etc.) then no living will be being made from designing them. Thus there is the implication of an individual that has sufficient knowledge to design a 'working' engine that can be created. > Professional is no guarantee of quality. No quality/professionalism relationship was being asserted in the statement; "They are certainly not professionals applying scientific theories or methods. They are not engineers.". Professional or amateur, this is an area where there are rational (so 'scientific') principles/methods to be applied and where criticising people for failing to apply them is reasonable and valid. Richard.
From: Richard Cornford on 15 Nov 2009 11:27 David Mark wrote: >On Nov 15, 1:35 am, Garrett Smith wrote: >> Richard Cornford wrote: >>> 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.)) >> >> Was an SVG "filter" style property, as a string value:- Yes, that was the one I was thinking of. >> typeof el.style.filter >> >> "undefined". >> >> javascript:var s=document.body.style;alert( >> [typeof s.filter,"filter"in s]); >> >> elerts "undefined, true" > > Right. The collection item method is IE and "string". So > to sum up, typeof for native objects is specified and all > known implementations follow the specification in this > regard (and would be broken as designed otherwise). The > allowed results do not include "array". Host objects are > allowed to return anything, but save for one case, they > return native type names (and the exception is not "array" > either). And it would be a dubious assumption that a host > object returning typeof "array" means that the object is > an Array (certainly document.all !== undefined in FF > quirks mode). Earlier this year it was proposed that:- <URL: http://www.google.com/codesearch > - could be used to say something about the prevalence of this particular mystical incantation, by entering the search term:- typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript In March this year that search was finding 2000 entries, today it was finding 3000. There are some false positives, but their proportion has not increased. I did find one splendid example in those results:- if( typeof(this.ansObj[ltag.id] == "array") ) Obviously someone wasn't getting the code they wanted executed because no objects (including Arrays) were resulting in 'array' from a - typeof - operation, so they played around with the placement of the parenthesise until something happed. Of course the author of that code cannot appreciate that the string 'boolean' will never be false and so the whole - if - statement can be replaced with the contents of its block to achieve precisely the same outcome. > It's not 100%, but proof enough for me that the code in question > is at best superfluous (for native objects) and could be harmful > (for host objects). Yes, the odds of successfully treating any host object that id result in 'array' from a - typeof - test (if such an object did exist) as a javascript Array are extremely low. The very fact that the - typeof - operation is not resulting in 'object' means that the object is not an Array, and so it quite unlikely to have, for example, all the array methods. > As Richard has speculated (for some time), it is likely the > result of a misconception that has spread over the years > (programming by copying patterns can produce oddities like > this). I would still like to know who started this one off. The earliest example that was drawn to my attention was the one in JQurey, but I would hesitate to credit its authors with making an original mistake. Granted the JQurey example was immediately preceded with the comment; "// Need to use typeof to fight Safari childNodes crashes", but when you examine Safari (going back to its first version) the - typeof - result for - childNodes - collections was never 'array', so the comment was never about some host environment oddity. > I've certainly seen this particular example in a lot of scripts. I have seen a few thousand examples by now. > I'll give it to jQuery that they didn't demand "proof" for > this one. Of course, there's that pesky attribute "question". > And now I see they actually use window.eval. Whatever. ;-) Richard.
From: John G Harris on 15 Nov 2009 11:55
On Sat, 14 Nov 2009 at 22:33:57, in comp.lang.javascript, Eric Bednarz wrote: >David Mark <dmark.cinsoft(a)gmail.com> writes: > >> What is a software engineer? > >In the Netherlands at the time of writing, anything from a computer >science graduate to a HTML/CSS code monkey who can copy and paste >[insert javascript[insert naming controversy here] library name >here]-code. .... who is trying to convince management he deserves a higher salary. Real engineers are people who desperately want to be promoted to management in order to get away from this nasty technical stuff. You can shout at a person and say that it's all their fault; if you start shouting at transistors they'll fetch the men in white coats. John -- John Harris |