WITH (this) {a;b;c}

V

VK

4.2.1

<snip> restored: " 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).
 
V

VK

P.S. On the FAQ "What is the best book to learn JavaScript?" I guess I

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.
 
R

Richard Cornford

VK said:
<snip> restored: " That is, constructors are not
required to name or assign values to all or any of
the constructed object's properties. "


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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top