By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,727 Members | 768 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,727 IT Pros & Developers. It's quick & easy.

WITH (this) {a;b;c}

P: n/a
WITH (this) {
a = 5
}

I'm finding that this.a = 5 will come from this expression. I would
have thought that the search for a would come up undefined and leave it
at that.

Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?

Nov 6 '06 #1
Share this Question
Share on Google+
27 Replies


P: n/a
VK

SamJs wrote:
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?
That is irrelevant to with() construct. If you assign a value to a
non-existing object property, the engine creates new property first and
then assign to it.

Nov 6 '06 #2

P: n/a
"SamJs" <Sa*******@gmail.comwrote:
WITH (this) {
a = 5
}

I'm finding that this.a = 5 will come from this expression. I would
have thought that the search for a would come up undefined and leave it
at that.
How strange, I would have thought you would get a syntax error from this
expression. Javascript doesn't have a 'WITH' statement (although it does
have a 'with' statement).
>
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?
Try this and you will find that assigning to 'a' doesn't create an
attribute on this:

f = function() {
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:undefined, window.a:42
but the following code will update the attribute on 'this':

window.a = undefined;
f = function() {
this.a = 'hello';
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:42, window.a:undefined
Nov 6 '06 #3

P: n/a
SamJs wrote:
WITH (this) {
a = 5
}

I'm finding that this.a = 5 will come from this expression.
Syntax error aside, that observation depends on the value of the this
operator. The this operator may, and often does, refer to the global object.

As long as there is no variable, a, within the scope chain, the
assignment expression above will create a new property on the global
object. If the this operator does indeed refer to that object, then the
expression

this.a

will evaluate to the number 5.

Compare to:

var object = {
method : function() {
with (this) {
a = 5;
}
alert(this.a);
}
};

object.method();

Here, the this operator refers to the object assigned to the variable,
object. As before, the assignment expression within the with statement
creates a property on the global object, but because the this operator
value is different, the expression evaluates to undefined.

[snip]
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?
Yes: it never happens. Only existing properties can be read or assigned.

Mike
Nov 6 '06 #4

P: n/a
Duncan Booth wrote:
"SamJs" <Sa*******@gmail.comwrote:
[...]
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?

Try this and you will find that assigning to 'a' doesn't create an
attribute on this:
Yes it does...
>
f = function() {
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:undefined, window.a:42
Because the value of this was the window object, so an a property was
added to window and assigned a value of 42.

but the following code will update the attribute on 'this':

window.a = undefined;
f = function() {
this.a = 'hello';
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:42, window.a:undefined
Because when you call f as a constructor, its this value is set to the
newly created object: this.<propertyNameassigns properties to the new
object.
--
Rob

Nov 6 '06 #5

P: n/a
"RobG" <rg***@iinet.net.auwrote:
Duncan Booth wrote:
>"SamJs" <Sa*******@gmail.comwrote:
[...]
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?

Try this and you will find that assigning to 'a' doesn't create an
attribute on this:

Yes it does...
Assignment never creates a new attribute on the object referred to in the
'with' statement.
>>
f = function() {
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:undefined, window.a:42

Because the value of this was the window object, so an a property was
added to window and assigned a value of 42.
Hello? Did you read the code?

f is called with the new operator. The value of 'this' inside the function
is the newly created object, not the window object. Neither has an 'a'
attribute to the assignment creates a new value on the global object (which
in this case happens to be the window object).
>
>but the following code will update the attribute on 'this':

window.a = undefined;
f = function() {
this.a = 'hello';
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:42, window.a:undefined

Because when you call f as a constructor, its this value is set to the
newly created object: this.<propertyNameassigns properties to the new
object.
Yes, 'this' is the same as in the first example. The difference this time
though is that this.a already exists so the assignment to plain 'a' updates
the existing attribute.
Nov 7 '06 #6

P: n/a
VK

Duncan Booth wrote:
Assignment never creates a new attribute on the object referred to in the
'with' statement.
Welcome to JavaScript :-) and you are wrong as it's already pointed out
:-(
If property doesn't exist yet, it will be conveniently created for you.
>
f = function() {
with(this) {
a = 42;
}
}
var g = new f();
alert("g.a:"+g.a+", window.a:"+window.a);
// displays: g.a:undefined, window.a:42
Because the value of this was the window object, so an a property was
added to window and assigned a value of 42.

Hello? Did you read the code?
It seems that you (as well as OP) are semi-mesmerized by with()
construct so presuming some hidden magic out of it: while it's nothing
but a shortcut tool.
with (this) {a = 'foo';}
programmatically is absolutely the same as
this.a = 'foo';

Try this:

function f() {
this.a = foo;
}

f();
alert(window.a); // 'foo'
var foo = new f();
alert(foo.a) // 'foo'

1] If property doesn't exist yet, it will be created during the
assignment.
2] The call context is everything in JavaScript

Nov 7 '06 #7

P: n/a
Duncan Booth wrote:
"SamJs" <Sa*******@gmail.comwrote:
Is JavaScript explicit about the behavior of creating variables on a
WITH (object) ?
[...]
Assignment never creates a new attribute on the object referred to in the
'with' statement.
So Mike said - maybe I should have believed him. :-)

[...]
Did you read the code?
Yes, but it didn't sink in at the time. I don't use with, and probably
never will - thanks to this discussion I have a better idea of how it
works.
--
Rob

Nov 7 '06 #8

P: n/a
VK

VK wrote:
Assignment never creates a new attribute on the object referred to in the
'with' statement.
Humply swallow my words back

<script>
function f() {
with(this) {
a = 'foo';
}
}

f();
alert(window.a); // foo
var foo = new f();
alert(foo.a); // undefined
</script>

Interesting...

Nov 7 '06 #9

P: n/a
VK wrote:
VK wrote:
>Duncan Booth wrote:
>>Assignment never creates a new attribute on the object referred to
in the 'with' statement.
Welcome to JavaScript :-) and you are wrong as it's already pointed
out :-(
If property doesn't exist yet, it will be conveniently created for you.
Humply swallow my words back

<script>
function f() {
with(this) {
a = 'foo';
}
}

f();
alert(window.a); // foo
var foo = new f();
alert(foo.a); // undefined
</script>

Interesting...
As you have never managed to grasp the difference between scope chain
Identifier resolution and property accessor resolution you may find
seeing the expected result "interesting". In reality all you are doing
is again demonstrating that your ignorance of javascript, and fictional
perceptions of it lead you to repeatedly making false statements about
javascript, and wasting everyone's time reading them and correcting the
more coherent ones.

Richard.

Nov 7 '06 #10

P: n/a
VK
Richard Cornford wrote:
As you have never managed to grasp the difference between scope chain
Identifier resolution and property accessor resolution you may find
seeing the expected result "interesting". In reality all you are doing
is again demonstrating that your ignorance of javascript, and fictional
perceptions of it lead you to repeatedly making false statements about
javascript, and wasting everyone's time reading them and correcting the
more coherent ones.
Richard, don't be so boring (and so well-predictable).
:-)

It is interesting indeed because the expected result (with
"Activation/Zombification" stuff flushed out and with "expected" fill
free to replace if you want with "expected by totally ignorant
programmers like VK"): the result would be the scope chain studied for
an object having [a] property and if no one found then *come back* to
the default object and add such property into it. Thus with() should be
acting as what it is: a shortcut where
someObject.someOtherObject.someProperty = 'foo';
and
with (someObject.someOtherObject) {
someProperty = 'foo';
}
doing the same thing.

That hits back I guess to the badly implemented with() mechanics in
JavaScript and in the particular the lack of default object accessor
shortcut.

Nov 7 '06 #11

P: n/a
VK wrote:
Richard Cornford wrote:
>As you have never managed to grasp the difference between scope chain
Identifier resolution and property accessor resolution you may find
seeing the expected result "interesting". In reality all you are doing
is again demonstrating that your ignorance of javascript, and fictional
perceptions of it lead you to repeatedly making false statements about
javascript, and wasting everyone's time reading them and correcting the
more coherent ones.

Richard, don't be so boring (and so well-predictable).
:-)

It is interesting indeed because the expected result (with
"Activation/Zombification" stuff flushed out and with "expected"
fill free to replace if you want with "expected by totally ignorant
programmers like VK"):
That is near gibberish. But "expected by people who don't understand
javascript" will do.
the result would be the scope chain studied for
an object having [a] property and if no one found then *come back* to
the default object
By "default object" I assume you are again referring to the object at
the top of the scope chain.

Why would you expect the scope chain resolution of an Identifier to
"come back" to the top of the scope chain in the context of a - with -
statement when it does not do so in any other context?
and add such property into it. Thus with() should be
acting as what it is: a shortcut
Who said it was a 'shortcut'?
where
someObject.someOtherObject.someProperty = 'foo';
and
with (someObject.someOtherObject) {
someProperty = 'foo';
}
doing the same thing.

That hits back I guess to the badly implemented with()
mechanics in JavaScript and
The - with - statement in javascript does what it does; adds an object
to the top of the scope chain. How - with - statements may work in
other languages has no baring on whether that is a good or bad
implementation. Understanding what a - with - statement does in
javascript, and how javascript works (particularly with regard to the
resolution of Identifiers, and assignment to Identifiers) explains the
behaviour of code in - with - statements.
in the particular the lack
of default object accessor shortcut.
Javascript has never provided direct access to objects on the scope
chain.

Richard.

Nov 7 '06 #12

P: n/a
Thank you to everyone for the effort put into this thread. I have
reservations about responding at all after reading the words in some of
the posts, but it seems to me more important to provide some kind of
closure.

I was wrong in my observation in the initial post. I read this thread
- twice - and built my own test script (included below) both to confirm
the thread and as pennance for beginning the thread with an erronious
observation. On digging deeper, I found that the properties which I
thought were being created were in fact declared elsewhere.

JavaScript does not read or write to with(object) properties which do
not exist.

It is riskier to use with () (as opposed to an explicit reference) as
the scope chain will be explored if a property is not found.

The only point I disagree with is the point of with(obj) not resulting
in shorter code. Perhaps not for a one-line situation, but when
several lines of code are involved, with(obj) can not only reduce the
coding, but can make the code easier to read.

Here's my test script. The results change slightly and in an expected
manner if the function reference is preceeded with "new".

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
/>
<title>Untitled Document</title>
</head>

<body>
<script type="text/javascript">
var a

var myObj = {
b: undefined,

myFunc: function(c) {
var d
with (this) {
a = "Mares eat oats."; // Should assign to Global variable a
b = "Does eat oats."; // Should assign to myObj.b (same as this.b)
unless "new function" is used
c = "Little lambs eat ivy."; // Should assign to parameter c
d = "A kidd'l lee divey two."; // Should assign to local variable d
e = "Wouldn't you?"; // Should create and assign to global variable
e
};
alert('this.a: ' + this.a); // undefined
alert('this.b: ' + this.b); // Does eat oats (undefined if new
function())
alert('this.c: ' + this.c); // undefined
alert('this.d: ' + this.d); // undefined
alert('this.e: ' + this.e); // undefined
return;
}
}

// Do it
myObj.myFunc('howdy dowdy');
alert('global.a: ' + (typeof a == "undefined" ? "undefined" : a)); //
Mares eat oats
alert('global.b: ' + (typeof b == "undefined" ? "undefined" : b)); //
undefined
alert('global.c: ' + (typeof c == "undefined" ? "undefined" : c)); //
undefined
alert('global.d: ' + (typeof d == "undefined" ? "undefined" : d)); //
undefined
alert('global.e: ' + (typeof e == "undefined" ? "undefined" : e)); //
Wouldn't you?

</script>
</body>
</html>

Nov 7 '06 #13

P: n/a
"SamJs" <Sa*******@gmail.comwrote:
The only point I disagree with is the point of with(obj) not resulting
in shorter code. Perhaps not for a one-line situation, but when
several lines of code are involved, with(obj) can not only reduce the
coding, but can make the code easier to read.
Shorter maybe, but I'm not so sure about easier to read:
with (this) {
a = "Mares eat oats.";
b = "Does eat oats.";
c = "Little lambs eat ivy.";
d = "A kidd'l lee divey two.";
e = "Wouldn't you?";
};
when you come back to that code in 6 months time you are going to have a
merry chase figuring out what scope each variable was in.

This on the other hand makes the scopes explicit:

with (this) {
window.a = "Mares eat oats.";
this.b = "Does eat oats.";
c = "Little lambs eat ivy.";
d = "A kidd'l lee divey two.";
window.e = "Wouldn't you?";
};

Of course, you could argue that I was unfair deleting your comments, but if
you add them back in then my code is shorter. :)

The other thing you've missed is that a trivial change a long way away from
your with statement could completely change the effect of the code in an
unexpected way. Assigning myObj.a=1 anywhere in the code changes the
meaning of the assignment to a inside the with. This kind of brittle code
should be avoided where possible.
Nov 7 '06 #14

P: n/a
Duncan Booth wrote:
This on the other hand makes the scopes explicit:

with (this) {
window.a = "Mares eat oats.";
this.b = "Does eat oats.";
c = "Little lambs eat ivy.";
d = "A kidd'l lee divey two.";
window.e = "Wouldn't you?";
};
.... and I should have of course trimmed the no longer needed 'with(this)'.
Nov 7 '06 #15

P: n/a
In article <11*********************@f16g2000cwb.googlegroups. com>, SamJs
<Sa*******@gmail.comwrites

<snip>
><script type="text/javascript">
var a

var myObj = {
b: undefined,

myFunc: function(c) {
var d
with (this) {
a = "Mares eat oats."; // Should assign to Global variable a
<snip>

But not if some maniac has given the Object prototype a property named
"a".

Write 100 times : "with is dangerous" :-)

John
--
John Harris
Nov 7 '06 #16

P: n/a
In JavaScript1.5, with(object){
field=xxx;
}
requare object.field has been created.

Nov 9 '06 #17

P: n/a
Lich_Ray wrote:
In JavaScript1.5, with(object){
field=xxx;
}
requare object.field has been created.
In what sense "require"? That code is syntactically correct and has well
defined and certain behaviour, even if any object referred to by -
object - has no - field - property. If the assignment is intended to
influence a property of the - object - object then it must have a -
filed - property, but that is true for all ECMAScript implementations,
not jsut JavaScript(tm) 1.5.

Richard.
Nov 9 '06 #18

P: n/a
VK

Lich_Ray wrote:
In JavaScript1.5, with(object){
field=xxx;
}
requare object.field has been created.

Lich_Ray wrote:
In JavaScript1.5, with(object){
field=xxx;
}
requare object.field has been created.
Alas you may want to study over your testcase. As it was pointed by
others
with(someObject) {
missingProperty = 'value';
}
missingProperty will never be created for someObject. Instead the
engine will go along the scope chain to never come back again. If no
object with ["missingProperty"] property found anywhere, at the end of
the scope chain will be Global object and the engine will create new
property for this object. In more conventional terms it means that new
global variable missingProperty will be created.
This way with() acts as some kind of highly weird "mode strict" clause
with non-predeclared properties disregarded for the involved object but
polluting the global space.
However old the tradition of this weirdness would be (I traced it back
to Netscape 4.5) it is totally unacceptable now with element ID's
accounted as global variables (IE and now Firefox in Quirk mode).
It may lead to the most obscure errors one can imagine. See for
example:

<html>
<head>
<title>Test</title>
<script type="text/javascript">

function Shipping(c) {
this.carrier = c || 'unknown';
this.package = new Object();
with(this.package) {
container = 'big';
}
}

function init() {
var delivery = new Shipping();
}

window.onload = init;
</script>
</head>
<body>
<div id="container">Content</div>
</body>
</html>

IE simply reports "Object doesn't support this property or method"
because global "container" is already taken by DIVElement and you
cannot assign string values to a DOM element reference.

I'm not exactly sure what a hey Firefox is doing: it seems like it
studies on parsing stage all left hand side identifiers inside with{}
blocks and pre-declares them as global ones (as if they had var
keyword). (Anyone having a better explanation please welcome).

The only reasonable solution of this mess as I see it is to implement
the algorithm I suggested before: study the scope chain, if no match
found anywhere than come back to the default object and create new
property for it.
I don't see how would it affect any legacy scripts as I doubt very
much anyone ever used with(someObject){} construct as a way to create
global variables (?)

Nov 9 '06 #19

P: n/a
VK wrote:

[snip]
with(someObject) {
missingProperty = 'value';
}
missingProperty will never be created for someObject. Instead the
engine will go along the scope chain to never come back again.
Why can't you just say that the identifier cannot be resolved, that it
doesn't exist as a property of an object within the scope chain?

[snip]
This way with() acts as some kind of highly weird "mode strict"
clause with non-predeclared properties disregarded for the involved
object but polluting the global space.
What on Earth is that supposed to mean?

The with statement temporarily adds a new object to the top of the scope
chain. That's all.

[Assigning to variables created from id attribute values]
IE simply reports "Object doesn't support this property or method"
because global "container" is already taken by DIVElement and you
cannot assign string values to a DOM element reference.
Sorry? Did you manage to forget that this is a loosely-typed language?
One does not assign to references, one assigns to variables and
properties, and these may change type and value at any time. Attempting
to assign to a read-only property does not raise an exception; it is
ignored.
I'm not exactly sure what a hey Firefox is doing:
What I wrote above should make it obvious. The question should be: What
is Microsoft doing?
it seems like it studies on parsing stage all left hand side
identifiers inside with{} blocks and pre-declares them as global ones
(as if they had var keyword).
It's amazing how simple things just fly right over your head.

[snip]

Mike
Nov 9 '06 #20

P: n/a
VK

Michael Winter wrote:
What I wrote above should make it obvious. The question should be: What
is Microsoft doing?
It doesn't allow to override global variables created for ID'ed
elements (treated as Const). The only known salvation is to predeclare
all variables in your code with var: such declarations take precedence
over "ID pollution". Crazy - but maybe not so bad for enforcing proper
programming style on developers :-). At the same time catastrophic for
the lazy coders and the with(){} amateurs (in the sense "who likes
something").

Actually: where is in ECMAScript 3ed exactly spelled that in case
someObject.nonExistingProperty="foo" nonExistingProperty has to be
created (rather than throw error). I tried to find, but I cannot read
Books of ECMA more than 30sec in the row, I'm getting nuts :-) The
exact section number would be appreciated.

Nov 9 '06 #21

P: n/a
VK wrote:
Michael Winter wrote:
>What I wrote above should make it obvious. The question should be:
What is Microsoft doing?

It doesn't allow to override global variables created for ID'ed
elements
<snip>

Global variables are not created for IDed element, named properties of
the global object are created instead. The distinction will be lost on
you but they do explain some of the behaviour observed. Particularly
the fact that a global variable cannot be created with the - ReadOnly -
attribute, but a host may create a property of an object with that
attribute.
Actually: where is in ECMAScript 3ed exactly spelled that in case
someObject.nonExistingProperty="foo" nonExistingProperty has
to be created (rather than throw error).
If the [[CanPut]] method of the object returns false then the property
must not be created, but no exceptions are thrown. You are typically
vague in your assertion but if your use of the name
"nonExistingProperty" implies that the object itself _and_ none of its
prototypes has an existing property with that name, _and_ the object is
a native ECMAScript object, then the property must be created on the
object.
I tried to find, but I cannot read
Books of ECMA more than 30sec in the row,
I'm getting nuts :-)
Getting?
The exact section number would be appreciated.
ECMA 262, 3rd Ed. Sections 10.1.4, 11.2.1, 11.13.1, 8.7.1, 8.7.2,
8.6.2.2 and 8.6.2.3

Richard.

Nov 9 '06 #22

P: n/a
VK
The exact section number would be appreciated.
ECMA 262, 3rd Ed. Sections 10.1.4, 11.2.1, 11.13.1, 8.7.1, 8.7.2,
8.6.2.2 and 8.6.2.3
Wow, so many numbers and not a single hit.
Thanks the advansed text search exists:

4.2.1
Unlike class-based object languages, properties can be added to objects
dynamically by assigning values to them. That is, constructors are not
required to name or assign values to all or any of the constructed
object's properties.

Nov 9 '06 #23

P: n/a
VK wrote:
>>The exact section number would be appreciated.
>ECMA 262, 3rd Ed. Sections 10.1.4, 11.2.1, 11.13.1, 8.7.1, 8.7.2,
8.6.2.2 and 8.6.2.3

Wow, so many numbers and not a single hit.
Thanks the advansed text search exists:

4.2.1
Unlike class-based object languages, properties can be added to
objects dynamically by assigning values to them. ...
<snip>

There is an obvious distinction between "can be added to objects
dynamically by assigning values to them'" and 'must be added to objects
dynamically by the assignment of values to them'. Though I doubt you
would see that.

Richard.

Nov 9 '06 #24

P: n/a
VK
4.2.1
Unlike class-based object languages, properties can be added to
objects dynamically by assigning values to them. ...
<snip>
<sniprestored: " That is, constructors are not
required to name or assign values to all or any of the constructed
object's properties. "
There is an obvious distinction between "can be added to objects
dynamically by assigning values to them'" and 'must be added to objects
dynamically by the assignment of values to them'. Though I doubt you
would see that.
With the end of the paragraph (which you so "conveniently" snipped) it
is obvious for any English speaker that "can" here refers to further
object augmentation even after leaving the constructor: which is indeed
is not an obvious feature for say C++ programmer so requires a special
mention. It doesn't mean that "property can be added or can be not
added depending on the weather conditions" as you tried to translate.

But after carefully reading the Book of Statements, Song 12:10 :-) "The
with statement" I see no basis for a real dispute. Obviously no one of
authors programmed with VB languages so they simply overlooked the case
with a new property of the default object located left-hand-side and
instantiated over the assignment.

This way there is no hook to attach it to 8.6.2.2 Whatever was done -
it was done. IMHO - and kill me but I stay on it - from all options the
absolutely worst was chosen; but there is no formal reasons to
complain.
P.S. On the FAQ "What is the best book to learn JavaScript?" I guess I
have my own anwer:
- The one that warns about with(){} behavior with non-existing
properties. In any book open "with" article (it is almost always
separate) and check what it says. If it mentions the caveat from this
thread, you have much lesser risk to vaste your money for junk.
Out of curiousity: does Flannagan talk about it? (I never had this
book).

Nov 9 '06 #25

P: n/a
VK wrote:
P.S. On the FAQ "What is the best book to learn JavaScript?" I guess I
have my own anwer:
- The one that warns about with(){} behavior with non-existing
properties.
Just avoid with altogether:
http://www.javascripttoolbox.com/bestpractices/#with

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 9 '06 #26

P: n/a
VK
P.S. On the FAQ "What is the best book to learn JavaScript?" I guess I
have my own anwer:
- The one that warns about with(){} behavior with non-existing
properties.
Just avoid with altogether:
http://www.javascripttoolbox.com/bestpractices/#with
As a "best practice" can be a good advise - unless special cases like
CC over with()
Yet with(){} statement is not a deprecated/obsolete/not supported
language feature: it is official part of the language. This way any
printed JavaScript book has to spend at least one paragraph to mention
it. The way it will be mentioned can be used as a rather robust way to
sort out hash-hash from the serious literature. This is what I meant to
say.

Nov 9 '06 #27

P: n/a
VK wrote:
>>4.2.1
Unlike class-based object languages, properties can be
added to objects dynamically by assigning values to
them. ...
<snip>

<sniprestored: " That is, constructors are not
required to name or assign values to all or any of
the constructed object's properties. "
>There is an obvious distinction between "can be added to
objects dynamically by assigning values to them'" and
'must be added to objects dynamically by the assignment
of values to them'. Though I doubt you would see that.

With the end of the paragraph (which you so "conveniently"
snipped) it is obvious for any English speaker that "can"
here refers to further object augmentation even after
leaving the constructor:
That is obvious without the last paragraph. the point that I did not
expect you to comprehend is that "can" does not mean "must". And whether
the object is created with a constructor or not does not change that at
all.

It is astounding how much effort you put into not understanding
javascript. I posted the section numbers of all the algorithms involved
in assigning a value to an object property, and if you had read those you
(or rather anyone rational) should have seen that assignment does not
necessarily result in the creation of a property of an object when the
object does not have such a property to start with. And so why; "can be
added to objects dynamically by assigning values to them'" does not mean
'must be added to objects dynamically by the assignment of values to
them'.

Instead of reading the pertinent sections you have gone of into the
descriptive section of the specification in search of something that
would justify your false assertion that "in case
someObject.nonExistingProperty="foo" nonExistingProperty has to be
created" and then misinterpreted what you found as saying something other
than does say. It is no wonder than your self-proclaimed 10 years
experience of 'using' javascript has left you with no technical
understanding of the language, and left you writing code that you do not
even understand yourself.
which is indeed is not an obvious feature for say C++
programmer so requires a special mention.
I am sure that programmer of any sort would rather be told the truth
about javascript than hear another of your misconceptions.
It doesn't mean that "property can be added or can
be not added depending on the weather conditions"
as you tried to translate.
As I tried to "translate" or as you tried to misrepresent? My statement
was factual and accurate; because you *can* create previously
non-existing named properties of an object by assigning values to
properties of that object using those names does not mean that assigning
values to those named properties will result in the creation of
properties of that object. This is both implied by the meaning of the
word "can" in English and evident in the algorithms specified for the
assignment operation.

To demonstrate:-

<html>
<head>
<title></title>
</head>
<body>
<script type="text/javascript">
document.write(
'document.compatMode = '+
document.compatMode+
'<br><br>'
);

function AnObject(){

}
AnObject.prototype = parseInt;

var obj = new AnObject();

document.write(
'obj.hasOwnProperty("length") = '+
obj.hasOwnProperty("length")+
'<br>'
); // false

obj.length = 8; // assign a value to the length property
// of the constructed AnObject instance.

document.write(
'obj.hasOwnProperty("length") = '+
obj.hasOwnProperty("length")
); // still false.

</script>
</body>
</html>
- in which an object is created (using a constructor, as you seem to
think that has some relevance to the subject) and it is verified with
the - hasOwnProperty - method of the object that it does not have a -
length - property. Then a value is assigned to the - length - property of
that object, and finally the - hasOwnProperty - is used again to
determine whether the assignment resulted in the creation of a - length -
property of that object. The results demonstrate that the object does not
have a length property following its creation, and that the act of
executing an assignment of a value to the - length - properly of the
object does not result in the creation of a - length - property of the
object.

So while you certainly *can* add properties to instances of the native
ECMAScript object at runtime the act of assigning is not guaranteed to
create previously non-existing property of on a native ECMAScript obejct.
But after carefully reading
Do you really man "careful reading" or do you mean determined
misconceiving? You were, after all, reading the wrong sections when it
came to understanding the relationship between the assignment of values
to properties and the creation of properties on object. And you have not
understood the real meaning of the section that you did read, apparently
because you don't understand the word "can".
the Book of Statements, Song 12:10 :-)
"The with statement" I see no basis for a real dispute.
What you see when you misconceive the text of the specification has no
baring on anything.
Obviously no one of authors programmed with VB languages
Is it "obvious" that the Microsoft representatives on the ECMA committee
would have no experience of Visual Basic? It seems more likely that they
realised that they were writing a specification for javascript rather
than Visual Basic.
so they simply overlooked the case with a new property
of the default object located left-hand-side and
instantiated over the assignment.
There is no object in javascript that is comparable to the default object
in VB. In so far as any documentation uses the term "default object" in
javascript they only use it as an alternative term for the object at the
top of the scope chain. The relationship between Identifier resolution
and the objects on the scope chain has been fully specified and seems to
have been completely considered in the specification. Which contrasts
with your understanding of the mechanism, which is so poor that you have
asserted here that:-

| The only reasonable solution of this mess as I see it is to implement
| the algorithm I suggested before: study the scope chain, if no match
| found anywhere than come back to the default object and create new
| property for it.
|
| I don't see how would it affect any legacy scripts ...

- when in reality such a change in the mechanism would radically alter
the nature of the language and instantly break a huge proportion of
existing scripts (baring in mind that the object at the top of the scope
chain (your "default object") is normally the Activation/Variable object
for the execution convex, and so your proposed change would have
assignments to undeclared Identifiers creating what were effectively
local variables instead of what are effectively global variables).
This way there is no hook to attach it to 8.6.2.2 Whatever
was done - it was done. IMHO - and kill me but I stay on it
- from all options the absolutely worst was chosen; but there
is no formal reasons to complain.
Your opinions are, as always, worthless.
P.S. On the FAQ "What is the best book to learn JavaScript?"
I guess I have my own anwer:
- The one that warns about with(){} behavior with non-existing
properties. In any book open "with" article (it is almost always
separate) and check what it says. If it mentions the caveat from
this thread, you have much lesser risk to vaste your money for junk.
You would have people looking for the wrong thing in the wrong place
(which isn't that surprising as it is your habit, as demonstrated here,
is to spend your time looking in the wrong place for the wrong thing).
The - with - section only has to explain that the object will be added to
the top of the scope chain, while another section explains how Identifier
resolution against the scope chain works and how assignments are handled
when Identifiers cannot be resolved.
Out of curiousity: does Flannagan talk about it?
That would make more sense if you had written "what does Flanagan *say*
about it?' or 'what does Flanagan *write* about it?'
(I never had this book).
That shows.

Richard.
Nov 9 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.