Re: Need Help Creating an Image Slideshow

Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
The OP should not be presented with ill-advised code.

But I did not present such code. IMHO the original poster received a
workable example of good quality.

IYHO.

The test of `Image' being [[Construct]]able is certainly necessary.
However, only its [[Call]]ability can be determined with probability
*and* compatibility.
Let's see. Can you name a reasonable browser where 'var a = new Image
();' fails ? I can't.
That does not mean anything.

Okay, let me name you one then: the ancient Netscape Navigator 2.01.
from 1995 - I just tested. The question remains: which reasonable
browser would fail to execute 'var a = new Image();' ?

You still miss the point.

But I only wanted to backup my statement that Image and Array have
been supported since javascript 1.1. That information is not outdated
at all.
Yes, it is, regarding `Image' (will you please drop `Array' now? I have
never said that it needed to be feature-tested anymore!). When a feature,
(here: Image) is not part of a programming language (here: JavaScript) since
more than a century, documentation that claims its availability is obsolete
regarding a discussion that is based on current versions of said programming
language.

Empty over-theorising.

Not at all.

It is simply no problem to use the Image-object.

That remains to be seen. I am working on it.

Go to <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference>;
you will find no `Image' object there, and rightly so.

It's not in the 1.4 reference either
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.4/reference/

I think I have said that before. Nevertheless, as I indicated before, too,
JavaScript 1.4 is not a good example because it has never been implemented
client-side. So I chose the next implemented version for the comparison.

Your observation is correct, your conclusion is wrong.

No. Your arguments are based on wishful thinking.

I proposed
if (t == f.length)
and you want
if (t > f.length - 1)
:-)
Your new proposition is arguably more efficient than your previous one,
but neither as safe, nor safer or more efficient than mine.

Bla bla bla.

Very eloquent.

A construction 'if (t == f.length)' is much better than
'if (t > f.length - 1)' on all aspects.

No, it is not. To begin with, `==' does some unnecessary type checks, and
let's the script break if one decides to increment by more than one. You
would have known if you knew what you are talking about and had read the
ECMAScript Language Specification, Edition 3 Final, sections 11.9.1 and
11.9.3, or simply performed a few tests.

In which cases is the Image-object unsupported ?
See above.

Netscape Navigator 2.01. ?

Probably yes. Hardly relevant nowadays, though.

Feature-testing and Object/Array initializers are common programming
techniques today.
Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
"undefined") {...' is absurdism in its most pure form.
How so? `document' is either a property of a host object in the scope
chain, or a host-defined property of the Global Object since more than a
century; its availability depends on the host environment, and not on the
language version.

Utterly absurd!
Check http://www.google.com/search?q=javascript+document
Which of the 17.600.000 results uses feature-detecting on 'document'
before invoking it ?

You're right, we really should eat ***. A million flies can't be wrong.

[...]
You would rather continue writing error-prone code in
order to avoid feature-testing code that you do not understand, yes?

You know I am an advocate of feature detection - I'm using it all the
time - but not in absurd cases like this. Image objects have been
around since js 1.1.

Again, it does not matter what the language version was when (not: if) the
feature is no longer part of the language since more than a century. The
earlier you get this, the earlier you will be writing scripts that do not
break when exposed to a previously unknown environment.

and are extremely unlikely to disappear towards the future.

We'll see. For example, it stands to reason that a user agent that does
not show images but implements ECMAScript does not need to provide Image
objects.


PointedEars
.

Loading