«

On Nov 15, 12:20*am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
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.))
>

The - item - method of DOM collections I think. So yeah, in reported
history, there are a handful of host object typeof anomalies and all
but one - unknown - are native type names. Not one "array" in the
bunch.

On Nov 14, 11:36*pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

[...]

>
> 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.
>

And I think it goes without saying that such arbitrary constraints are
confining even on the desktop. But for scripts with mobile
aspirations (one of the reasons dynamic script loading is being
considered) it seems like the worst possible choice.

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:-

typeof el.style.filter

"undefined".

javascript:var s=document.body.style;alert([typeof s.filter,"filter"in s]);

elerts "undefined, true"
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 15, 1:35*am, Garrett Smith <dhtmlkitc...@gmail.com> 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:-
>
> 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).

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). 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've certainly
seen this particular example in a lot of scripts. 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.

David Mark wrote:
> On Nov 15, 1:35 am, Garrett Smith <dhtmlkitc...@gmail.com> 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:-
>>
>> typeof el.style.filter
>>
>> "undefined".
>>
>> javascript:var s=document.body.style;alert([typeof s.filter,"filter"in s]);
>>
>> elerts "undefined, true"
>

And:

javascript:var s=document.body.style;prompt('',[typeof s.filter, s]);

results:

undefined,[object CSSStyleDeclaration]

> 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).

Ah, not completely.

We recently discussed callable regexp.

In Spidermonkey typeof /a/ results "object" (where it should, by
following the typeof table, result "function". This is because RegExp is
callable in Spidermonkey, using Function Call syntax as:

/a/("a");// results ["a"]

javascript: alert( /a/("a") )

elerts "a"
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Nov 15, 2:41*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Nov 15, 1:35 am, Garrett Smith <dhtmlkitc...@gmail.com> 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:-
>
> >> typeof el.style.filter
>
> >> "undefined".
>
> >> javascript:var s=document.body.style;alert([typeof s.filter,"filter"in s]);
>
> >> elerts "undefined, true"
>
> And:
>
> javascript:var s=document.body.style;prompt('',[typeof s.filter, s]);
>
> results:
>
> undefined,[object CSSStyleDeclaration]
>
> > 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). *
>
> Ah, not completely.
>
> We recently discussed callable regexp.
>
> In Spidermonkey typeof /a/ results "object" (where it should, by
> following the typeof table, result "function". This is because RegExp is
> callable in Spidermonkey, using Function Call syntax as:
>
> /a/("a");// results ["a"]
>
> * *javascript: alert( */a/("a") )
>
> elerts "a"

Fair enough, but it is still within the specified range for native
types.

Richard Cornford 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 possibility nonetheless, which disproves the "never". Nothing more,
nothing less.

> a host object may result in any string when - typeof - is applied to it,

That was my point.

> 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. [...]

You appear to think that I said it would be a likely case; I did not.


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 <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

On Nov 15, 6:38*am, David Mark <dmark.cins...@gmail.com> wrote:
> What is a software engineer?

To me, an engineer is a skilled technical professional who is able to
apply scientific knowledge to solve practical problems.

[...]
> Would you hang your hat on this? *I've been asked by these engineers
> to "prove" that this is a bad idea (I say the proof is right there in
> the code). *They say they've never _seen_ it fail.

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".

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.


>*For this one, I
> don't know what that means (it's obviously designed to fail). *So when
> did programming becomes a process of gathering empirical evidence, as
> opposed to understanding logic? *Seems like browser scripting would be
> the worst discipline for such a change in strategy.

It is an extremely common strategy, encouraged by modern programming
environments that attempt to improve productivity by offering features
like IntelliSense, I call it programming by feel. If you dare
challenge the methodology, you'll be told they don't have time to
learn the language thoroughly, that they don't need to understand it
as long as it works.

The only explanation I have for why such programmers get away with it
is because their programs are compiled and very few ever get to see
the awfulness of the raw code. It seems that passing user acceptance
testing is the sole criterion of quality, that the source code totally
sucks is likely seen as a good way to make money on maintenance.


--
Rob

Richard Cornford wrote:

> 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.

You are rioght, but that behavior of `typeof' is not the same for
whole ActiveXObject instances in IE.

window.alert(typeof document.nodeType == 'unknown'); //false - typeof
number
window.alert(document instanceof ActiveXObject); //true

var XHR = new ActiveXObject('Microsoft.XMLHTTP');
window.alert(typeof XHR.open == 'unknown'); //true
window.alert(XHR instanceof ActiveXObject); //true

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.

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.

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.

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) 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.

Oh, and an explanation is not a theory, and certainly not a scientific
theory, nor is a scientific theory an explanation. It is if you like,
the expression of the result of a lot of experimental data in terms of
an algorithm. 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. That is borne out by observation. I am not sure it
explains anything at all. 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.

A professional engineer is one who makes his living out of designing
engines. HOW he does it, is really no part of what he is.

Professional is no guarantee of quality.