Daz said:
Ouch... My purpose was to give an example that could be seen working,
not do do it for him. He wanted to know how to achieve, and I did that
in my example. It's not meant to be code that can be copied and handed
in as school work (if that's what it's for).
Still, would you agree that wrong examples serve little practical purpose?
Are you talking about recursion?
Hardly. What would recursion have to do with the above?
I'd be interested to see your implementation.
Why, the "implementation" is listen to mouse and keyboard events,
particularly mousedown, mouseup, click, keyup, keydown, and keypress.
That, I didn't know. What does setInterval() use then, if it's not
system ticks?
It does use system timer ticks which is the cause of the problem with it
when it comes to time-critical applications.
I was always under the impression that they were built
on the same foundations, but just worked differently.
I read an interesting and IMHO sound argument about setInterval() vs.
setTimeout() in another thread here not long ago, but I don't have the
reference anymore. IIRC, it goes like this:
ECMAScript implementations are single-threaded. window.setInterval()
*attempts* to execute code every n milliseconds despite of that. Consider
that at that time another process/thread has priority, there are two
possibilities: either the application will execute the interval code
at the next available tick, or it will execute it at the next planned
opportunity, n milliseconds after the tick that could not be used.
Either way, the supposed calls are likely to accumulate here.
With setTimeout(), the application will have no choice but to execute it
at the next available tick; and only then the new timeout will be set.
So nothing can accumulate then.
I know this, although I don't see much of a point...
Not calling them as methods of Window objects assumes that the Global Object
or an unknown host object in the scope chain has such host-defined
properties. This would be error-prone.
I suppose you write all of your global variable and functions like
that too?
Of course not. Those are properties of the Global Object, not of a host
object that may or may not be available as such and may or may not share
the Global Object's properties. If I would do what you assume, that would
be error-prone, too.
The JavaScript 1.5 Reference already states:
,-<
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects
|
| The [G]lobal [O]bject itself can be accessed by `this' in the global
| scope.
And rightly so; that is specified in ECMA-262 since its very first edition.
That was the OP's code, and if that's what he wanted to do, that's
down to him. What's wrong with just answering a question rather than
answering a whole heap of questions he didn't even ask?
If you had the intention to give him a hint as how to solve his problem, it
would have been a Good Thing to post a reasonable example, even though the
original code was bad. That would not have involved "answering a whole head
of questions": a short note as to why it is bad along with the improved code
would have sufficed.
That this newsgroup is not a newsgroup dealing primarily with HTML is a
null argument; we are attempting to write good code here, no matter the
language. In fact, it turns out that bad HTML, CSS etc. code often is
the cause of a script written in an ECMAScript implementation not to
function. You simply can't build a house on quicksand.
Validation may reveal your problem - It wouldn't. The problem was with
the method (not even the JavaScript itself...
Validation may solve your problem - Again, it wouldn't.
You can not know that.
[...]
Validation is an indicator of cluefulness - I couldn't agree more, but
we are talking about HTML validation for a JavaScript problem, when
you know as well as I do that wasn't the problem. Also, it's pretty
obvious that the OP isn't experienced.
So the logical course of action would be to deny them access to further
knowledge?
That was my bad. I meant to actually say "object". That's exactly what
it is, but it does "act" like a multi-dimensional array.
It does not.
document.forms.anotherForm.elementName
This is completely proprietary referencing, and so inherently error-prone.
Mostly standards-compliant and fully backwards-compatible referencing of the
above would be
document.forms["anotherForm"].elements["elementName"]
You can also access it like this:
document["forms"]["anotherForm"]["someChildName"]
That is not standards-compliant either.
document["forms"]["anotherForm"]["elements"]["someChildName"]
would be.
Please could you post a link to the documentation that states this?
I did.
I have to admit, I did go through a time when I didn't know whether to
use dot notation or object literals. Generally, I use dot notation
unless I need to call on a dynamically generated property.
I use jslint.com to validate my HTML.
I put both of our lines of script into a variable, and checked it with
JSLint.
var el = document["forms"]["anotherForm"]["elements"]["someChildName"]
Error:
Implied global: document
Problem at line 1 character 19: ['forms'] is better written in dot
notation.
The statement is correct. That should have been only a warning, though.
var el = document["forms"]["anotherForm"]["elements"]["someChildName"]
Problem at line 1 character 28: ['anotherForm'] is better written in
dot notation.
That is incorrect, as I have pointed out and referred to reference material.
If you think my single line of code is wrong, perhaps you should take
it up with Douglas Crockford? I don't mean that in a horrible way, I'd
just be interested to see what he says.
jslint is a tool to check for possible errors and bad code style. It does
not recognize the context of a script. That is not really a flaw of it, but
something that has to be considered by people who use it.
As Douglas Crockford is a regular here, I am pretty sure he will comment on
that eventually.
Again, I didn't say my methods were correct, I simply stated that it
was another way of doing it.
Proposing bad style is a Bad Thing, period.
As I wrote, you could simply have refrained from replying to the OP.
A more knowledgable person than you would most certainly have replied
with a much better S/N ratio.
You mean "dereferencing"?
That would imply ECMAScript implementations have a concept of pointers,
which they have not.
Then we'll have to agree to disagree. Perhaps it's just me,
No, it is a common misconception about the language, last but not least
transported or induced into the mind of beginners by bad books.
but it sounds like you just "described" a multi-dimensional array. I didn't
say it "was" a multi-dimensional array, I simply compared it to one.
Here's a multi-dimensional array:
There isn't. I have explained already why, mentioning exactly the below
example. But as you insist:
That is creating a new Array object and assigning the reference to it
to the previously instantiated variable `arr'.
I will assume in the following for brevity that `arr' is a global variable.
arr["first_property"] = 1;
That is adding the `first_property' property with value 1 to the Array object.
arr.length remains 0. arr.join("") yields "", not "1".
arr["second_property"] = 2;
That is adding the `second_property' property with value 2 to the Array object.
arr.length remains 0. arr.join("") yields "", not "12".
arr["third_property"] = [];
That is adding the `third_property' property with a reference to a new Array
object to the Array object referenced with `arr'
arr.length remains 0. arr.join("") yields "", not "12".
arr["third_property"]["first_property"] = 4;
That is adding the `first_property' property with the value 0 as property of
the array object referenced by arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124". arr["third_property"].join("") yields "", not "4".
arr["third_property"]["second_property"] = function() { alert(5); };
That is adding the `second_property' property with a reference to a new
Function object as property of the Array object referenced by
arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124,function() { alert(5); }".
arr["third_property"].join("") yields "", not "4function() { alert(5); }".
arr["third_property"]["third_property"] = 6;
That is adding the `third_property' property with a reference to a new
Function object as property of the array object referenced by
arr["third_property"].
Both arr.length and arr["third_property"].length remain 0. arr.join("")
yields "", not "124,function() { alert(5); },6".
arr["third_property"].join("") yields "", not "4function() { alert(5); }6".
alert(arr.second_property);
That is calling the alert() method (of Window objects, error-prone called as
a method of the Global Object or another object in the scope chain). It is
passed the evaluation of the dot property access to the `arr' property of
the Global Object, which yields an (Array) object; that object has a
`second_property' property which is of type number; the value is converted
to string with ToString(), and (maybe) displayed.
arr.third_property.second_property();
That is evaluated as follows: `arr' is determined a property of the Global
Object, which yields an (Array) object; that object has a `third_property'
property which yields an (Array) object; that object has a second_property
property which is of type Function; the grammar dictates that because of
the (empty) parameter list and the absence of the `new' keyword, that
Function object must [[Call]]ed, which is then done.
Here's the equivilant object:
The only equivalence here is that all objects may have properties, and that
native objects, such as Object objects and Array objects, may be added
(user-defined) properties.
This is creating a new Object object, and assigning a reference to the
previously instantiated variable `obj'. That object inherits only from
Object.prototype; not from Array.prototype as the object referenced with
`arr' does.
I won't repeat the above. Suffice it to say that
obj["first_property"] = 1;
is (of course) equivalent. The difference is only the property accessor
syntax used.
obj["second_property"] = 2;
obj["third_property"] = {};
obj.third_property.first_property = 4;
obj["third_property"].first_property = 4;
or
obj["third_property"]["first_property"] = 4;
obj.third_property.second_property = function() { alert(5) };
obj["third_property"].second_property = function() { alert(5) };
or
obj["third_property"]["second_property"] = function() { alert(5) };
obj.third_property.third_property = 6;
obj["third_property"].third_property = 6;
or
obj["third_property"]["third_property"] = 6;
alert(obj.second_property);
alert(obj["second_property"]);
or (better)
window.alert(obj["second_property"]);
obj.third_property.second_property();
obj["third_property"].second_property();
or
obj["third_property"]["second_property"]();
They are different methods of "Basically" achieving the same thing.
That much is true.
Array() is based on an object (as is everything else), the only
fundamental differences are the properties and methods.
There is much more to Array objects (see ECMA-262 Ed. 3), if array
properties are used.
As they are not used here, the fundamental difference is that the Array
object wastes more memory, and inherits more properties and methods from
its prototype object (which inherits from Object.prototype) that are not
used but can interfere.
So an Object object, which inherits only from Object.prototype, should
have been used in the first place (no matter the property access syntax used).
Please don't start ranting about recommendations and standards.
Mentioning recommendations and standards is only ranting for those who fail
to recognize their utmost significance when it comes to interoperability.
I am well aware that it's not standard,
You are not aware that the language specification explicitly allows that
approach for *native* objects. Which does not mean in any way that it would
be wise to (mis)use Array objects like this.
However, DOM interfaces are a completely different thing. The standard for
*that*, W3C DOM Level 2 HTML, states that bracket property accessors must be
used for referencing items of HTMLCollection objects. It is specified so,
period.
but it should illustrate that when I compared an object is basically a
multi-dimensional array, that there is truth in that.
Not in the least.
Again, I didn't say "it was", I simply compared them.
Your comparison was based on a (common) misconception.
But your statement at least implied this. Don't try to wind around that.
(sic!)
You have destroyed the context.
So in your effort to "not do someone's homework for them", you've
actually gone and done it for them.
You are confused. I have never stated that I would "not do someone's
homework for them" (although I would probably not do that without proper
compensation in any form). However, you made it necessary to correct your
wrong example and false statements (or implications, if you wish). If not
only you but also others, including the OP, can learn from that, so be it.
Still, the unlearning that is now required by them (again; if they even
recognized or understood the correction(s) which ended up being quite large
because of the sheer number of errors) would not have been necessary, and
could have been avoided in the first place.
PointedEars
