"Professional Javascript" review

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

I doubt anyone is thinking of VBScript at this juncture. *And you
aren't thinking at all (as usual).

With your own programming skills I would remain silent, really.

[nonsense skept]

Lasse Reichstein Nielsen wrote:

Variables can have types in JavaScript 2.0, but not in ECMAScript so
far. Values have types. Variables have a value, but not an inherent
type.

That is another (but a very round around) way to say that JavaScript
is a loosely typed language. There are untyped languages like
VBScript, where no matter what value is currently assigned to a
variable, its type is the same universal Variant. There are loosely
typed languages like JavaScript where at each moment each variable has
a strictly defined type depending on the value it points to. There are
strictly typed languages like Java where on initialization stage we
have to indicate what type of values this variable can point to, and
we cannot change it at runtime. JavaScript from the beginning and till
now is loosely typed language. It might add optional strictly typed
features in the future to please some C-grounded hearts but so far
this disaster is not actual.

Null is a primitive value in javascript.

Another wrong statement: null in JavaScript is an object with the only
property null:
*window.alert(typeof null) // 'object'

No, null is a primitive (i.e., non-object) value.
Notice the specification of the typeof operator needs a special case
for null, because it is not an object (ECMA 262 section 11.4.3).

It needs a separate row because it goes by types, and Null type
returns "object". But OK, "null is a primitive value with typeof
"object" by a bizarre demand of specs"

This way by assigning null to an object reference, we are
dereferencing the said object.

You can't assign a value to a value (object references are values),
and I don't think "dereferencing" means what you think it means.

Yes, "unlink" might be better.

If it is the last existing reference
then the relevant scavenger will be marked as garbage collection
available on the next GC check. Not sure what is so alien here in
comparison with other languages.

True, if you overwrite a variable holding an object reference with
null, that might make the object eligable for garbage collection, but
the same happens if you assign a number to the variable. Nothing
non-primitive about null in that case.

Yes, in JavaScript one may "unlink" an object by setting all variables
pointing to it to 0, 1, "foobar" or anything else. It is possible in a
loosely typed language yet extremely awkward. In strictly typed
languages though it will lead to an error because you cannot assign
non-reference value to a reference value variable. So to uniform
JavaScript with the common programming practice and do not make your
code looking silly it is still suggested to "unlink" using null
assignments, not any other fantasy values.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

Plainly false: in global context [this] refers to the window host
object, not to Global.

What makes you think they are different?

For Gecko and IE: respective explanations from MDC and MSDN and team
blogs, I posted the relevant materials since 2006 here.

In a browser setting, the global object and the "this" value is
actually not necessarily the same object, but ECMA-262 says nothing
about browsers.
It does say that the "this" value for code executed in a Global
Context is the global object. If browsers differ, it's because they
are not completely ECMA-262 compliant (with good reason, usually
security related).

I thought the topic of discussion is about practical programming and a
book giving advises on it. If we want to discuss programming issue for
an abstract ECMA 262 3rd.ed. machine then it will be totally another
topic IMHO

On Oct 31, 2:27*pm, Lasse Reichstein Nielsen <lrn.unr... (AT) gmail (DOT) com>
wrote:

[...]

What makes you think they are different?

Are you really asking VK to answer this?

In a browser setting, the global object and the "this" value is
actually not necessarily the same object, but ECMA-262 says nothing
about browsers.
It does say that the "this" value for code executed in a Global
Context is the global object. If browsers differ, it's because they
are not completely ECMA-262 compliant (with good reason, usually
security related).

I don't know of any ECMAScript implementation that varies in that
regard (browser or not). It certainly wouldn't be a good
implementation.

But VK is hung up on the window object, which isn't specified anywhere
other than in browser documentation (an aside in ECMA-262 about
browsers notwithstanding).

"Additional host defined properties. This may include a property whose
value is the global object itself; for example, in the HTML document
object model the window property of the global object is the global
object itself."

This is not a standard, but is sometimes cited as if it were. In
reality, resemblances between that *implementation dependent* host
object and the Global Object may or may not indicate they are the same
object. Doesn't matter at all for most developers. Then there's VK...

VK wrote:

Garrett Smith wrote:
Javascript variables are untyped.

It is hard to imagine anyone taking that the statements you have made
seriously.

How could you believe what you have written? I hope that it is not some
form of sabotage.

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

No, my statement is correct. Variables are untyped.

Nowhere are variables defined to have a type.

Unless you can back that statement up with some thing from the
specification. Alas, you have not; nor can you, so the reader is left
with the options of taking your word over the specification.

Variables are initialised to undefined when created.

var x;

The value of a variable can change in an assignment expression:

x = 10;
x = "foo";
x = {};

All of that is allowed by the specification.

Nowhere does the specification mention variable types.

If x were typed, it would not have a very clear type, now, we see the
value change from |undefined| to a number, a string value, finally an
object.

A /value/ could be said to be typed, as there are many places in the
specification that mention if [value] is a [type], or:-

A string value is a member of the type String

A variable is not a member of any Type. That is not how javascript
works.

Contrast that to Java, where variables are typed.

<URL:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html >

every variable and every expression has a type that is known at
compile time. Types limit the values that a variable (§4.12) can hold
or that an expression can produce, limit the operations supported on
those values, and determine the meaning of the operations. Strong
typing helps detect errors at compile time.

And in Java:-

String x = "foo";
x = 10; // won't compile.

However:

String = 10 + "";

should compile fine.

Null is a primitive value in javascript.

Another wrong statement: null in JavaScript is an object with the only
property null:

No, null is a primitive value. Being a primitive value, null has no
properties, and so cannot have a property named "null".

A primitive value is not an object or reference.

The Null type is not an object Type.

4.3.12 Null Type
The type Null has exactly one value, called null.

4.3.2 Primitive Value
A primitive value is a member of one of the types Undefined, Null,
Boolean, Number, or String

The ECMA specification is clear that null is a primitive value, not an
object.

Need more evidence?

9.1 ToPrimitive

Input Type Result
Undefined The result equals the input argument (no conversion).
Null The result equals the input argument (no conversion).
...

If Null type were an object type, it would not make much sense for
ToPrimitive to convert null to null. OTOH, in reality, null is a
primitive:

7.8.1
The value of the null literal null is the sole value of the Null type,
namely null.

10.2.3

note that null is not an object

window.alert(typeof null) // 'object'

Works as designed (though that design is questionable).

The result of the typeof operator does make null an object.

The value null a primitive value.

This way by assigning null to an object reference, we are
dereferencing the said object. If it is the last existing reference
then the relevant scavenger will be marked as garbage collection
available on the next GC check. Not sure what is so alien here in
comparison with other languages.

I'm having a hard time following that explanation.

In contrast, the specification clearly explains null.

| Another misleading assertion was — "Though ECMA-262 doesn’t indicate a
| way to access the Global object directly […]".

Plainly false. In global context:

var global = this;

Plainly false: in global context [this] refers to the window host
object, not to Global. Let's do not mix "syntax sugar" added atop in
some engine implementations with the actual mechanics, it might be
dangerous.

The |this| value in global context is the global object. This is clearly
explained in ECMA-262 specification, s10.2.1.

The |this| value is the global object.

It is your word against the ECMA-262 r3 specification.

Do you really think the specification is wrong and you are correct?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

VK wrote:

That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

Garrett Smith wrote:

No, my statement is correct. Variables are untyped.

Nowhere are variables defined to have a type.

(further similar nonsense removed)

You know guys, at the run of one week you just killed me, really. For
some time I did believe that some posters here are professional
programmers with CS diplomas trying to learn yet another language
different from C++. So I attributed their obvious beserknesses to the
classical CS education - so being forgiven to some rather wide extend.
But the discussion at "Implicit object constructor misinterpretation"
and comments like here did force me to change my mind. Now if I ever
believe that you had any CS education, then only in some
conspiratorial school "Witnesses of Integer" or similar of the kind
Because no normal place you could came from with such a luggage of
pseudo-philosophic twisted definitions of nearly anything from the the
most core programming entities.

I am not arguing with you anymore. You are definitely right, the Earth
is flat and stays on three elephants.

For other possible readers a few random links on the subject below.
Also of course do not take some anonymous VK poster as being right by
definition. Go and ask at MIT, Berkley, Carnegie Mellon or other
reputable CS department for explanations.

Typeless language
http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_eves.mspx

Loosely (dynamically) typed language
http://www.computerhope.com/jargon/l/looslang.htm
http://msdn.microsoft.com/en-us/library/14cd3459%28VS.85%29.aspx
http://www.java2s.com/Tutorial/JavaScript/0100__Number-Data-Type/Variablesarelooselytyped.htm
see also: type coercion

Strongly (statically) typed language
http://www.computerhope.com/jargon/s/strolang.htm

VK <schools_ring (AT) yahoo (DOT) com> writes:

You know guys, at the run of one week you just killed me, really. For
some time I did believe that some posters here are professional
programmers with CS diplomas trying to learn yet another language
different from C++. So I attributed their obvious beserknesses to the
classical CS education - so being forgiven to some rather wide extend.
But the discussion at "Implicit object constructor misinterpretation"
and comments like here did force me to change my mind. Now if I ever
believe that you had any CS education, then only in some
conspiratorial school "Witnesses of Integer" or similar of the kind
Because no normal place you could came from with such a luggage of
pseudo-philosophic twisted definitions of nearly anything from the the
most core programming entities.

Nothing like abuse to make people shut up. Just don't mistake silence
for agreement after it, though.

Anyway, if everybody else disagrees with you, perhaps you should
entertain the idea that it might not be all of them who are in the
wrong.

Wars have been fought over the meaning of "strongly typed". Is it the
same as "statically typed" or does it mean that values can't change
their type, or one of the other six interpretations given at
<URL:http://en.wikipedia.org/wiki/Strongly_typed_programming_language>?

You are very strict in your insistence that Javascript is "loosely
typed", which is a name that is not even mentioned at
<URL:http://en.wikipedia.org/wiki/Type_system>
I can see that it is a term often used about "scripting like" languages,
to mean that you don't declare a variable to have a type, and you can
assign values of different types to the same variable.
Given the disagreement about "strongly typed", I can see the need for
a different name (other than "weakly typed") for this property.

You then insist that variables have types, because the opposite has to
be like VBScript's Variant type (which also fails the second
definition of "strongly typed" above, if I understand your description
of it correctly).
That's not what is usually meant by a variable having a type.

Variables have values, and values have types. Ofcourse you can say
that the variable has the type of its current value, but that is not
a type that is inherent in the variable. This is opposite languages
like Java, where variables do have a type.

For other possible readers a few random links on the subject below.
Also of course do not take some anonymous VK poster as being right by
definition. Go and ask at MIT, Berkley, Carnegie Mellon or other
reputable CS department for explanations.

Typeless language
http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_eves.mspx

From this, it seems that VBScript acts identically to JavaScript.
Variables can hold any value, and doesn't have a type. The values
still have types, but are automatically coerced to another type if
necessary.

Loosely (dynamically) typed language
http://www.computerhope.com/jargon/l/looslang.htm
http://msdn.microsoft.com/en-us/library/14cd3459%28VS.85%29.aspx
http://www.java2s.com/Tutorial/JavaScript/0100__Number-Data-Type/Variablesarelooselytyped.htm
see also: type coercion

Strongly (statically) typed language
http://www.computerhope.com/jargon/s/strolang.htm

I accept that "loosly typed", as used in these links, also describe
JavaScript. I still maintain that a variable doesn't have a type in
a loosely typed language, in the sense normally meant by variables
having a type.

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Lasse Reichstein Nielsen wrote:

Nothing like abuse to make people shut up. Just don't mistake silence
for agreement after it, though.

If I made you feel insulted then sorry.

Anyway, if everybody else disagrees with you, perhaps you should
entertain the idea that it might not be all of them who are in the
wrong.

It may happen though and happened many times. Yet I am not expressing
some unknown theory no one else in the world ever expressed yet. That
makes a big difference.

Wars have been fought over the meaning of "strongly typed". Is it the
same as "statically typed" or does it mean that values can't change
their type, or one of the other six interpretations given at
URL:http://en.wikipedia.org/wiki/Strongly_typed_programming_language>?

You are very strict in your insistence that Javascript is "loosely
typed", which is a name that is not even mentioned at
*<URL:http://en.wikipedia.org/wiki/Type_system
I can see that it is a term often used about "scripting like" languages,
to mean that you don't declare a variable to have a type, and you can
assign values of different types to the same variable.
Given the disagreement about "strongly typed", I can see the need for
a different name (other than "weakly typed") for this property.

The language is defined as loosely typed by the original creators
(Netscape docs) and by Microsoft. OK, neither Netscape nor Microsoft
had a clue about programming and the right term usage and only a few
individuals at clj have it. We may accept this as an alternative
theory but who's theory is more exotic then?
If declaring Java variables like
int i;
boolean isFound;
we are not declaring some variable types irrelevant to the values they
hold: I never heard about such thinking approach anywhere outside of
clj and I do communicate with professional programmers in San Jose on
a daily basis. We simply have to announse in advance what types of
values variable i or isFound can point to and we cannot change or to
extend our decision later (casting issues aside).
OK, again let's assume no one understand the programming properly but
some people at clj.
I still don't understand why should I fill myself alienated by sharing
the most common opinion against 2-5 opinions expressed in a Usenet
group.

You then insist that variables have types

See above. Variables do not have types, it is just a common shortcut
no one thought to be needed to explain or being leading to a
confusion. Values are of different types, and in strictly typed
languages one need to decide in advance what value type this or that
variable may hold at runtime.
In loosely typed languages such decision is not necessary because any
variable can hold any value type. It doesn't mean that there are no
types: for each separate type (Object, Boolean etc) there is a
different scavenger structure and each given moment each variable has
a strictly defined type - depending on the type of value it holds.
That is the difference from typeless languages where there are not
type distinctions so any values are represented by the same scavenger
type and having one universal type no matter what you assign: 1,
"foobar", false, objRef etc. Say in VBScript such universal type is
called Variant.
It is so easy and obvious even to me, having no classical education in
CS. It is obvious to my friends and partners who have such education.
It leads to some enormous understanding problems at clj, just like
with identifier definition which I never met in my life anywhere
outside of clj. Really, I showed the thread about the object
constructor to a professional C++ programmer who's my subcontractor
for years. He spent about 15 mins to get to the point of others
argumentation and then his only reaction was "wow!"
I don't want to insult anyone anymore, so let's say "wow!" means
"yeah, these guys are really bright ones".

VK wrote:

VK wrote:
That's a wrong statement, you must be thinking of VBScript where
indeed all variables independently on the current value are of the
same Variant type. JavaScript is a *loosely typed* language, that
means that each variable is of some certain type but this type can be
changed to another one at runtime.

Garrett Smith wrote:
No, my statement is correct. Variables are untyped.

Nowhere are variables defined to have a type.

(further similar nonsense removed)

You have not read the ECMA specification, in all these years?

It's only 170 pages.

You know guys, at the run of one week you just killed me, really. For
some time I did believe that some posters here are professional

Want to be professional? Read the specification. Understand the
language.

programmers with CS diplomas trying to learn yet another language
different from C++. So I attributed their obvious beserknesses to the
classical CS education - so being forgiven to some rather wide extend.
But the discussion at "Implicit object constructor misinterpretation"
and comments like here did force me to change my mind. Now if I ever
believe that you had any CS education, then only in some
conspiratorial school "Witnesses of Integer" or similar of the kind
Because no normal place you could came from with such a luggage of
pseudo-philosophic twisted definitions of nearly anything from the the
most core programming entities.

What you call "Psuedo-philosophic twisted definitions" I call the
ECMAScript specification.

I can and have read it. You may read it, too. Anyone may.

I am not arguing with you anymore. You are definitely right, the Earth
is flat and stays on three elephants.

That looks like a pretty obvious straw man.

For other possible readers a few random links on the subject below.
Also of course do not take some anonymous VK poster as being right by
definition. Go and ask at MIT, Berkley, Carnegie Mellon or other
reputable CS department for explanations.

The pertinent resource here is the ECMA-262 specification.

Typeless language
http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_eves.mspx

That is a tutorial for VBScript. It has nothing to do with anything
about ECMAScript. It is totally irrelevant.

Loosely (dynamically) typed language
http://www.computerhope.com/jargon/l/looslang.htm

A non-normative definition for jargon term "loosely typed language".

http://msdn.microsoft.com/en-us/library/14cd3459%28VS.85%29.aspx

Getting warmer on that one. JScript is Microsoft's implementation of
ECMAScript.

Microsoft's documentation is fine for learning. It should be a first
stop for implementors who copy IE-only properties (they usually bungle
that, and in so doing, make standardizing and codifying such properties
even harder).

Keep in mind that it is fairly often misleading, often features
non-interoperable code (works in IE only).

It correctly states:

You cannot explicitly declare data types in JScript.

And if you contrast that to what you wrote earlier:

variable is of some certain type but this type can be changed to
another one at runtime

Either variables have a type or they do not. Both cannot be true. It is
essentially a logical tautology.

The ECMAScript specification is the pertinent reference to answer that
question.

Bottom line: That link is not an authoritative reference for ECMAScript.

http://www.java2s.com/Tutorial/JavaScript/0100__Number-Data-Type/Variablesarelooselytyped.htm
see also: type coercion

Those references are not normative references on javascript. Regardless,
the tutorial seems to go against your claim of variables being typed by
stating:

variables in JavaScript are not given a specific type.

Compare to what you first wrote:

variable is of some certain type

Strongly (statically) typed language
http://www.computerhope.com/jargon/s/strolang.htm

At this point, it is unclear what (or if) you are trying to argue. You
seem full of hot air and have nothing valuable to say.

Such contributions to c.l.js detract from the quality of the NG.

They are detrimental to learning (it seems hard to believe that anyone
could find what you wrote useful, truthful, or valuable. At least a few
will read it.

You've contributed arrogance, misinformation, irrelevance.

Instead, you could have avoided doing that by either:
1) reading the pertinent specification
2) not partaking in the discussion
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Sun, 1 Nov 2009 at 02:34:20, in comp.lang.javascript, VK wrote:

<snip>

You know guys, at the run of one week you just killed me, really.
...
But the discussion at "Implicit object constructor misinterpretation"
and comments like here did force me to change my mind.
snip

You're just upset that no-one wants to believe your complicated and
incoherent description instead of our simple and clear version.

John
--
John Harris

John G Harris wrote:

You're just upset that no-one wants to believe your complicated and
incoherent description instead of our simple and clear version.
------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If that was a joke then a really good one - I admit it.