Webster van Robot help

[My Pet Programmer]

Steve Howell said:

Steve Howell said:

function World {
/* snip */
function wall_on_north(x, y)
{
if (y == 0 || y == this.num_streets) {
return true;
}
coords = x + "," + y;
return (north_walls[coords] == 1);
}
}

As written, that code does not actually work.

The method wall_on_north really does work, but I snipped out too much
context.

Giving some more context, but still striving for some brevity here:

function World() {
/* snip */
var north_walls = [];
this.num_streets = 10;


function wall_on_north(x, y)
{
if (y == 0 || y == this.num_streets) {
return true;
}
coords = x + "," + y;
return (north_walls[coords] == 1);
}
this.wall_on_north = wall_on_north;

}
the_world = new World();

First of all, forget about how wall_on_north is called from outside
World. It's created a bunch of red herrings that have nothing to do
with my question.

Next, look at the use of num_streets and north_walls above. With both
variables I have the inner function refer to variables that are to
meant to be within the scope of World(). In one case, num_streets, I
use "this" to make the scope explicit. In the other case,
"north_walls," I let JS figure out the scope.

(As for x and y, they're passed in parameters, and as for coords, it's
just a local variable.)

My question is fairly simple--what is the best practice for referring
to variables so that it's clear they're in the scope of World, i.e.
their scope is more than local to the inner function? My original
code had "this," but then David seemed to be suggesting that was
somehow wrong.

function World() { is a
better first line, but accepting that....

You say "function World() {" is a better first line...a better first
line than what? Isn't that what I showed?

The constructor I got was:
function World {


I sent a couple links over, did you get those? I haven't seen them post
to the list, but they give you a much better idea of what you're dealing
with here:
http://javascript.crockford.com/private.html

Is a really good one.

~A!

 

[Steve Howell]

Steve Howell said:

Steve Howell said:
function World {
/* snip */
function wall_on_north(x, y)
{
if (y == 0 || y == this.num_streets) {
return true;
}
coords = x + "," + y;
return (north_walls[coords] == 1);
}
}
As written, that code does not actually work.

The method wall_on_north really does work, but I snipped out too much
context.

Giving some more context, but still striving for some brevity here:

function World() {
/* snip */
var north_walls = [];
this.num_streets = 10;

function wall_on_north(x, y)
{
if (y == 0 || y == this.num_streets) {
return true;
}
coords = x + "," + y;
return (north_walls[coords] == 1);
}
this.wall_on_north = wall_on_north;

}
the_world = new World();

First of all, forget about how wall_on_north is called from outside
World. It's created a bunch of red herrings that have nothing to do
with my question.

Next, look at the use of num_streets and north_walls above. With both
variables I have the inner function refer to variables that are to
meant to be within the scope of World(). In one case, num_streets, I
use "this" to make the scope explicit. In the other case,
"north_walls," I let JS figure out the scope.

(As for x and y, they're passed in parameters, and as for coords, it's
just a local variable.)

My question is fairly simple--what is the best practice for referring
to variables so that it's clear they're in the scope of World, i.e.
their scope is more than local to the inner function? My original
code had "this," but then David seemed to be suggesting that was
somehow wrong.

You say "function World() {" is a better first line...a better first
line than what? Isn't that what I showed?

The constructor I got was:
function World {

Ok, my mistake.

I sent a couple links over, did you get those? I haven't seen them post
to the list, but they give you a much better idea of what you're dealing
with here:http://javascript.crockford.com/private.html

Is a really good one.

Thanks, I got both of the links, and they both are very helpful.

 

[Steve Howell]

Steve Howell said the following on 12/26/2007 2:21 AM:



Table cell attributes (width, height, etc..), or, are you talking about
modifying the table itself (adding cells)?

How you do the two is totally different.

Just the cell attributes. I shouldn't need to change the structure of
the table after I first create it. I will often be modifying two
cells at a time, possibly in two different rows. When I modify cells,
I may changing their contents, their attributes, or both.

If you run my posted code from earlier in the thread in Firefox, you
can see what I'm trying to do. Basically I'm just simulating a little
robot moving through Cartesian coordinates, and I occasionally draw
some walls, which I simulate via table cell borders. I've noticed
under Firefox that I if add a right border to the 3rd cell in the 7th
row, then that border gets extended down the 8th, 9th, 10th, etc. row.

 

[David Mark]

David Mark said the following on 12/26/2007 12:03 AM:

[snip]

function showMsg(the_message) {
  document.the_form.the_text.value += (the_message + "\n");
document.forms['the_form'].elements['the_test'].value += ...
Done.
The only time bracket notation makes any difference over dot notation is
if the form name or the element name has special characters in it with
meaning to Javascript. Otherwise, it is irrelevant.

Yes, the line could have been written:

document.forms.the_form.elements.the_test.value += ...

But that is not what he had.

The only difference between what he posted and what you posted is
personal preference. The *only* time the two are not equivalent is "if
the form name or the element name has special characters in it with
meaning to Javascript".

This is the original:

document.the_form.the_text.value

This would be the equivalent:

document.forms.the_form.elements.the_test.value

It is the implied forms and elements objects that are objectionable
(for numerous reasons.)

Besides, if you were going to tell him that Bracket Notation was better,

I wasn't.

[snip]

JSLint complaining about an optional feature in the language isn't a

Not my point.

reason to do it though. And, JSLint is not a JS engine. It is a language
syntax checker based on Douglas' personal beliefs about how the language
should be written.

It is also a great tool for spotting silly mistakes (e.g. typos.)

The statement ending semicolon is 100% optional.

Unless you plan to minify the code at some point.

I have asked in the past though, and only gotten one response and not a
very good explanation of that response to the question of "Can you show
real code where the lack of a statement ending semicolon causes a syntax
error and adding it removes that syntax error?"

var x, y y = 1;

var x, y; y = 1;

 

[Dr J R Stockton]

In comp.lang.javascript message <fd09fc21-6871-48f4-8055-fa2a807c4e3d@s8
g2000prg.googlegroups.com>, Tue, 25 Dec 2007 19:44:37, Steve Howell

Are there any tricks for debugging IE as it comes shipped? I am
getting cryptic errors like this:

Line: 19
Char: 1
Error: Object expected

Is the line number relative to the <script> statement?

Take a known-good page, insert an obvious script error, such as the
"statement" .. , and see what number results.

I find that the line number reported by IE6 is the line number of the
file, with numbering starting at zero. Do your own test for include
file errors.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

 

[David Mark]

David Mark said the following on 12/26/2007 12:21 PM:

David Mark said the following on 12/26/2007 12:03 AM:
[snip]
function showMsg(the_message) {
  document.the_form.the_text.value += (the_message + "\n");
document.forms['the_form'].elements['the_test'].value += ...
Done.
The only time bracket notation makes any difference over dot notationis
if the form name or the element name has special characters in it with
meaning to Javascript. Otherwise, it is irrelevant.
Yes, the line could have been written:
document.forms.the_form.elements.the_test.value += ...
But that is not what he had.
The only difference between what he posted and what you posted is
personal preference. The *only* time the two are not equivalent is "if
the form name or the element name has special characters in it with
meaning to Javascript".

This is the original:
document.the_form.the_text.value
This would be the equivalent:
document.forms.the_form.elements.the_test.value
It is the implied forms and elements objects that are objectionable
(for numerous reasons.)

Safari1.3 being one, and that pure dot notation being faster than
bracket notation?

I don't know that one is faster than the other, but I typically use
dot notation unless it isn't possible.

Personally, I use document.forms['formNAME'].elements[elementNAME']
simply because I use PHP on the server and elemRef[] in PHP gives fits
in JS.

I don't follow you there.

That I agree with.



Minifying code is a waste of time in my opinion, let's not go there

Just for the sake of argument, why is it a waste of time to remove
comments and unecessary whitespace? Granted HTTP compression (when
available) will take care of the whitespace pretty efficiently, but it
won't help with comments.

That is one statement, with a syntax error.
Right.


That is two statements without a syntax error. The semi-colon removed
the syntax error but it also changed the meaning of the code.

Yes, it is now two statements.

 

[David Mark]

David Mark said the following on 12/26/2007 11:27 PM:

David Mark said the following on 12/26/2007 12:21 PM:
David Mark said the following on 12/26/2007 12:03 AM:
[snip]
function showMsg(the_message) {
  document.the_form.the_text.value += (the_message + "\n");
document.forms['the_form'].elements['the_test'].value += ...
Done.
The only time bracket notation makes any difference over dot notation is
if the form name or the element name has special characters in it with
meaning to Javascript. Otherwise, it is irrelevant.
Yes, the line could have been written:
document.forms.the_form.elements.the_test.value += ...
But that is not what he had.
The only difference between what he posted and what you posted is
personal preference. The *only* time the two are not equivalent is "if
the form name or the element name has special characters in it with
meaning to Javascript".
This is the original:
document.the_form.the_text.value
This would be the equivalent:
document.forms.the_form.elements.the_test.value
It is the implied forms and elements objects that are objectionable
(for numerous reasons.)
Safari1.3 being one, and that pure dot notation being faster than
bracket notation?

I don't know that one is faster than the other, but I typically use
dot notation unless it isn't possible.

Pure dot notation, using just formname and elementname, has to be
faster. It is only doing 3 lookups instead of 5.

I meant between the two viable alternatives (both have 5 lookups.)