From: VK on
> > 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]
From: VK on
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 ;)
From: David Mark on
On Oct 31, 2:27 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.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...
From: Garrett Smith on
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/
From: VK on
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Limit of 4K
Next: Detecting Internet Explorer 6