Re: Javascript Best Practices Document v1.0

Thomas 'PointedEars' Lahn wrote:
> VK wrote:
>
> >> Detecting Browser Versions
> > ... and related scripts.
> >
> > I think that really best practice for object/method detection should be
> > the usage of "in" operator.
>
> Why should a not far enough downwards compatible feature be considered
> "best practice"?

By "not far enough" you mean NN 2.x - NN 4.x ? IE supports it since
3.02
If some other browser still doesn't have it implemented properly, the
primary task would be to see such browser disappeared from the human
memory as quick as possible, rather than support it an any way.

The most important is that if (someObject) method fails easily in too
many curcumstances appeared after prototypes and constructors
introduction. Check this sample:

<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function test() {

self.abort = undefined;

// Bad practice
// if (someObject.someMethod){...) method
// fails on prototype change
if (abort) {
alert('I still know it was originally here');
}
else {
alert('Oops, I\'ve been easily cheated');
}

// Good practice:
// if (someObject in objectContainer) {...} method
// works reliably on prototype change
// As one cannot use delete() on default property,
// you cannot be mislead in any situation
if('abort' in self) {
alert('Do not try to cheat me!');
}
else {
alert('Oops, I\'ve been cheated too');
}
}

alert(self.hasProperty)
</script>
</head>

<body bgcolor="#FFFFFF">
<form method="post" action="">
<input type="button" name="Button01" value="Test" onclick="test()">
</form>
</body>
</html>


> If really an ECMAScript 3 compliant approach would be taken, it would not be
> the "in" operator but the hasProperty() method which can much more easily
> be tested for than the former.

Where did you get method? You mean HasProperty moniker from .Net
framework? It has no relation with the discussion.

> Besides, "in" would seldom suffice as
> before calling a method you would need to make sure that it *is* a method
> and not a non-function property.

Why in the name you need to check the type of property in question?
What can it prove? Even if it's indeed a method (so it's typeof
"function"), what proof do you have that this is *that* method and not
some bogus? And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
The rest remains in the hands of the Lord and browser makers.


> Your assumption that `window' "nearly always" refers to the Global Object
> is wrong, by the way. There is a low probability that it does not within
> a HTML document context, but JS can be used in other contexts. And `self'
> is merely a property of `window', if existent, not of the Global Object;
> using it (untested) is only making bad things worse.

"self" has the only context to be. Unless you've created a "self"
variable and did your whole script dizzy:
....
self = something;
// var self = something ?
// window.self = something ?
....

As "self" is one of so-called "tasty words" for identifiers, I see this
happens here and there and should be each time pointed.

.