Also, I noticed that JSLint does not throw any warning at all for the Comma
Operator in the MDC example:

for (var i=0, j=9; i <= 9; i++, j--)
   document.writeln("a["+i+"]["+j+"]= " + a[i][j]);

Is that a mistake, or is this an acceptable use of commas?



--- In jslint_com@yahoogroups.com, "urangatang@..." <urangatang@...> wrote:
>
> I'm trying to clean up some code with JSLint, but I have been running
> into a problem with JSLint stopping prematurely when it comes across the
> Comma Operator
>
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Operator\s/Speci\
al_Operators/Comma_Operator> .
> Here is a simple example:

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:

> Some benefits of ECMAScript 5 strict mode:
>
> typeof [] returns "array" rather than "object"
> typeof null returns "null" rather than "object"

Not true. typeof remains broken. An Array.isArray method is added.

> If you forget to use "new" when using a constructor, like new Foobar(), it
will throw an error. Before, it would silently attach the constructor's
properties to the global object (usually window).

Not exactly. this will be bound to undefined, which might result in throwing.


> The special "this" variable correctly propagates within inner functions. For
instance, this code will run correctly:
>
> var foo = {
>     message: "Hello world",
>     saySomething: function () {
>         return (function () {
>             return this.message;
>         }());
>     }
> };

Not true. this in all inner functions is undefined.

That is perfectly valid and acceptable.

for (var i=0, j=9; i <= 9; i++, j--)
document.writeln("a["+i+"]["+j+"]= " + a[i][j]);

It is a standard for loop with the required three semicolon separated sections. 
The first section is a single var command applied to a list of variables.  The
third section defines how an iteration of the loop is manifest.  In this case
the loop cause the "i" variable to increment by one and the "j" variable to
simultaneously decrement by one.

From a stylistic perspective this type of looping is risky if closures are
contained in this loop.  The loop is logically solid and straight forward
because all that matter is the value of "i" for termination.  I say this loop is
risky because the loop changes the value of two variables simultaneously and
independently.  Any automated changes that occur simultaneously at absolute
independence from each other always result in higher levels of complexity for
debugging while possibly allowing a hidden conveyance for errors between
separate pieces of consuming logic.

Austin Cheney
http://prettydiff.com/

Even though it's not supported yet, I'd still like to understand
something about how this is supposed to work. I understand I can
include "use strict"; in a function so only that function is evaluated
in that mode. I'm unsure though what happens when that appears at the
top of a source file. Does it only affect that source file or does it
also effect other source files that are parsed after the current one?

--
R. Mark Volkmann
Object Computing, Inc.

Really! I heard talk about typeof being fixed. I guess they figured it would
cause too many compatibility problems so they cut it?

I also recall hearing about "this" being properly bound while within inner
functions. I wonder why that was changed.

Either way, sorry for the misinformation.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
>
> > Some benefits of ECMAScript 5 strict mode:
> >
> > typeof [] returns "array" rather than "object"
> > typeof null returns "null" rather than "object"
>
> Not true. typeof remains broken. An Array.isArray method is added.
>
> > If you forget to use "new" when using a constructor, like new Foobar(), it
will throw an error. Before, it would silently attach the constructor's
properties to the global object (usually window).
>
> Not exactly. this will be bound to undefined, which might result in throwing.
>
>
> > The special "this" variable correctly propagates within inner functions. For
instance, this code will run correctly:
> >
> > var foo = {
> >     message: "Hello world",
> >     saySomething: function () {
> >         return (function () {
> >             return this.message;
> >         }());
> >     }
> > };
>
> Not true. this in all inner functions is undefined.
>

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> Even though it's not supported yet, I'd still like to understand
> something about how this is supposed to work. I understand I can
> include "use strict"; in a function so only that function is evaluated
> in that mode. I'm unsure though what happens when that appears at the
> top of a source file. Does it only affect that source file or does it
> also effect other source files that are parsed after the current one?

It affects the whole file, and only the file. Strict functions can interact with
sloppy functions.

When linting this code:

   (function outer() {
       var foo = function() {
           bar();
       };

       var bar = function() {
       };

       foo();
   })();

JSLint gives me these warnings:

   Problem at line 3 character 5: 'bar' is not defined.
   Implied global: bar 3
   Unused variable: bar 1 outer

I think all three warnings are wrong. Due to type hoisting the 'var bar'
declaration applies to the entire scope of the 'outer' function, so foo()
inherits 'bar' from 'outer'.

Or am I missing something here?

best regards,
Bert

JSLint wants you to define functions before their first call is encountered.
While your code would work the way you haven't, it's considered better style
to change the order of your code.

On Tue, Jul 27, 2010 at 4:52 PM, Bert Belder <bertbelder@...> wrote:

>
>
> When linting this code:
>
> (function outer() {
> var foo = function() {
> bar();
> };
>
> var bar = function() {
> };
>
> foo();
> })();
>
> JSLint gives me these warnings:
>
> Problem at line 3 character 5: 'bar' is not defined.
> Implied global: bar 3
> Unused variable: bar 1 outer
>
> I think all three warnings are wrong. Due to type hoisting the 'var bar'
> declaration applies to the entire scope of the 'outer' function, so foo()
> inherits 'bar' from 'outer'.
>
> Or am I missing something here?
>
> best regards,
> Bert
>
>
>



--
R. Mark Volkmann
Object Computing, Inc.


[Non-text portions of this message have been removed]

Allright. But what if I have two functions that mutually call each other (that
was when I ran into this)? Then there is always one that is 'encountered' before
it is defined.

Furthermore, IMHO if JSLint isn't happy with a certain coding style, that's what
it should complain about -- instead of producing wrong statements about the
code.

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> JSLint wants you to define functions before their first call is encountered.
> While your code would work the way you haven't, it's considered better style
> to change the order of your code.
>
> On Tue, Jul 27, 2010 at 4:52 PM, Bert Belder <bertbelder@...> wrote:
>
> >
> >
> > When linting this code:
> >
> > (function outer() {
> > var foo = function() {
> > bar();
> > };
> >
> > var bar = function() {
> > };
> >
> > foo();
> > })();
> >
> > JSLint gives me these warnings:
> >
> > Problem at line 3 character 5: 'bar' is not defined.
> > Implied global: bar 3
> > Unused variable: bar 1 outer
> >
> > I think all three warnings are wrong. Due to type hoisting the 'var bar'
> > declaration applies to the entire scope of the 'outer' function, so foo()
> > inherits 'bar' from 'outer'.
> >
> > Or am I missing something here?
> >
> > best regards,
> > Bert
> >
> >
> >
>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
> [Non-text portions of this message have been removed]
>

You could use:

var foo, bar;

foo = function () {
     bar();
};

bar = function () {
     foo();
};

Marcel

On Tue, Jul 27, 2010 at 5:52 PM, bertbelder <bertbelder@...> wrote:

>
>
>
>
> Allright. But what if I have two functions that mutually call each other
> (that was when I ran into this)? Then there is always one that is
> 'encountered' before it is defined.
>
> Furthermore, IMHO if JSLint isn't happy with a certain coding style, that's
> what it should complain about -- instead of producing wrong statements about
> the code.
>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Mark
> Volkmann <r.mark.volkmann@...> wrote:
> >
> > JSLint wants you to define functions before their first call is
> encountered.
> > While your code would work the way you haven't, it's considered better
> style
> > to change the order of your code.
> >
> > On Tue, Jul 27, 2010 at 4:52 PM, Bert Belder <bertbelder@...> wrote:
> >
> > >
> > >
> > > When linting this code:
> > >
> > > (function outer() {
> > > var foo = function() {
> > > bar();
> > > };
> > >
> > > var bar = function() {
> > > };
> > >
> > > foo();
> > > })();
> > >
> > > JSLint gives me these warnings:
> > >
> > > Problem at line 3 character 5: 'bar' is not defined.
> > > Implied global: bar 3
> > > Unused variable: bar 1 outer
> > >
> > > I think all three warnings are wrong. Due to type hoisting the 'var
> bar'
> > > declaration applies to the entire scope of the 'outer' function, so
> foo()
> > > inherits 'bar' from 'outer'.
> > >
> > > Or am I missing something here?
> > >
> > > best regards,
> > > Bert
> > >
> > >
> > >
> >
> >
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>



--
Marcel Duran


[Non-text portions of this message have been removed]

These suggestions are all wrong.

The problem here is when a variable invoked and defined.

You can use:

function foo () {
bar();
}

function bar () {
var a = "1234";
}

In the previous example you will notice that function bar does not directly
point to a call to function foo, because function foo directly calls to function
bar.  If function bar did directly have a call to function foo there would be an
endless recursion.

You will also notice that the functions are invoked using the "function" keyword
directly and not with the "var" keyword.  Invoking functions with the "function"
moves the function to the top of the stack of the current parent so that
function calls can exist at any place in the given scope.

Functions invoked with the var command are treated just like every other
variable.  This means it must be declared before it is used or it will be both
undefined and an implied global.  This means the JSLint error output is not
being a pain in the ass, but is reporting a valid error.

Austin Cheney
http://prettydiff.com/

Hi all!  I've released an update to my jslint wrapper, jslint4java.  The
main change is that it can now produce JUnit XML output, enabling better
integration with continuous build systems like
pulse<http://zutubi.com/products/pulse/>and
hudson <http://hudson-ci.org/>.

For full details, see what's new:

http://code.google.com/p/jslint4java/#News

-Dom


[Non-text portions of this message have been removed]

Edward,

Starting your reply with "These suggestions are all wrong." is rude,
especially when they are not.

Here is the original code, modified so JSLint likes as much of it as
possible and including a couple of print statements so we can see if it
works.

(function outer() {
     var foo = function () {
         print('in foo');
         bar();
     };

     var bar = function () {
         print('in bar');
     };

     foo();
}());

JSLint has two complaints about this code.
1) at line 4, 'bar' is not defined.
2) at line 7, Too many var statements.

Complaint #1 is eliminated by simply reversing the order of the function
declarations.
Marcel's suggestion to declare foo and bar before they are defined
eliminates both issues in one shot.

Also, you said JSLint is reporting a valid error, but the code runs just
fine ... at least in Rhino.

On Tue, Jul 27, 2010 at 10:40 PM, Cheney, Edward A SSG RES USAR USARC <
austin.cheney@...> wrote:

>
>
> These suggestions are all wrong.
>
> The problem here is when a variable invoked and defined.
>
> You can use:
>
> function foo () {
> bar();
> }
>
> function bar () {
> var a = "1234";
> }
>
> In the previous example you will notice that function bar does not directly
> point to a call to function foo, because function foo directly calls to
> function bar. If function bar did directly have a call to function foo there
> would be an endless recursion.
>
> You will also notice that the functions are invoked using the "function"
> keyword directly and not with the "var" keyword. Invoking functions with the
> "function" moves the function to the top of the stack of the current parent
> so that function calls can exist at any place in the given scope.
>
> Functions invoked with the var command are treated just like every other
> variable. This means it must be declared before it is used or it will be
> both undefined and an implied global. This means the JSLint error output is
> not being a pain in the ass, but is reporting a valid error.
>
> Austin Cheney
> http://prettydiff.com/
>
>



--
R. Mark Volkmann
Object Computing, Inc.


[Non-text portions of this message have been removed]

I know that reversing the declaration order would fix the example code I posted.
However the situation that caused to me run into this doesn't really allow
reversing declaration orders without making the code really unreadable. Let me
explain.

Suppose you have to load several pieces of data *asynchronously* (using ajax for
example) where the next data source to be loaded depends on data loaded before.
Let's say the function `ajax(url, callback)` is defined, that does an ajax
request and calls the callback when the response arrives.
Then you could write:

var whatWereLookingFor;
ajax('/some/url', function(result) {
     ...
     ajax('/some/other/' + result.x, function(result) {
         ...
         ajax('/xyz/' + result.bar, function(result) {
             ...
             ajax('/bar/' + result.id, function(result) {
                 // Woohoo we got it
                 whatWereLookingFor = result;
             });
         });
     });
});

But that's terribly readable. So I was trying to write:

function loadSome() {
   ajax("/some/url", loadOther);
}
function loadOther(result) {
   ajax("/some/other/" + result.x, loadFoo);
}
function loadFoo(result) {
   ajax("/xyz/" + result.bar, loadBar);
}
function loadBar(result) {
   ...
}

But JSLint doesn't eat that.

The suggestion to reverse declaration order would solve the JSLint error, but
then the function that is called last would be defined first, which I think
would make the code confusing to a reader.

The other solution would be to put a statement like
var loadSome, loadOther, loadFoo, loadBar at the start of the function but that
clutters my code with unnecessary statements, besides requiring me to keep the
var statement in sync with the functions actually defined.

So, any suggestions here?

I don't really mind that JSLint complains when encountering a function call
before the function is defined. But I would be very happy if it would just say
that, and not mess up the implied globals list with variables that are NOT
global.

- Bert

On Wed, Jul 28, 2010 at 8:44 AM, bertbelder <bertbelder@...> wrote:

>
>
> I know that reversing the declaration order would fix the example code I
> posted. However the situation that caused to me run into this doesn't really
> allow reversing declaration orders without making the code really
> unreadable. Let me explain.
>
> Suppose you have to load several pieces of data *asynchronously* (using
> ajax for example) where the next data source to be loaded depends on data
> loaded before. Let's say the function `ajax(url, callback)` is defined, that
> does an ajax request and calls the callback when the response arrives.
> Then you could write:
>
> var whatWereLookingFor;
> ajax('/some/url', function(result) {
> ...
> ajax('/some/other/' + result.x, function(result) {
> ...
> ajax('/xyz/' + result.bar, function(result) {
> ...
> ajax('/bar/' + result.id, function(result) {
> // Woohoo we got it
> whatWereLookingFor = result;
> });
> });
> });
> });
>
> But that's terribly readable. So I was trying to write:
>
> function loadSome() {
> ajax("/some/url", loadOther);
> }
> function loadOther(result) {
> ajax("/some/other/" + result.x, loadFoo);
> }
> function loadFoo(result) {
> ajax("/xyz/" + result.bar, loadBar);
> }
> function loadBar(result) {
> ...
> }
>
> But JSLint doesn't eat that.
>
> The suggestion to reverse declaration order would solve the JSLint error,
> but then the function that is called last would be defined first, which I
> think would make the code confusing to a reader.
>
> The other solution would be to put a statement like
> var loadSome, loadOther, loadFoo, loadBar at the start of the function but
> that clutters my code with unnecessary statements, besides requiring me to
> keep the var statement in sync with the functions actually defined.
>
> So, any suggestions here?
>
> I don't really mind that JSLint complains when encountering a function call
> before the function is defined. But I would be very happy if it would just
> say that, and not mess up the implied globals list with variables that are
> NOT global.
>
> - Bert
>
Bert;

You're making a bunch of assumptions about your code. In the future you
might try to make some changes that will make your code wrong. Imagine in
your example:

(function outer() {
var foo = function() {
bar();
};

if (true) {
    return;
}

var bar = function() {
};

foo();
})();

Suddenly your variable does become global. JSLint recommends you define all
your variables at the top of each scope, so this kind of thing won't happen.
JSLint will hurt your feelings, but it makes your code better.


[Non-text portions of this message have been removed]

> You're making a bunch of assumptions about your code. In the future you
> might try to make some changes that will make your code wrong. Imagine in
> your example:
>
> (function outer() {
> var foo = function() {
> bar();
> };
>
> if (true) {
>    return;
> }
>
> var bar = function() {
> };
>
> foo();
> })();
>
> Suddenly your variable does become global. JSLint recommends you define all
> your variables at the top of each scope, so this kind of thing won't happen.

Erm, I don't see it. What becomes global then?

On Wed, Jul 28, 2010 at 9:07 AM, bertbelder <bertbelder@...> wrote:

>
>
> > You're making a bunch of assumptions about your code. In the future you
> > might try to make some changes that will make your code wrong. Imagine in
> > your example:
> >
> > (function outer() {
> > var foo = function() {
> > bar();
> > };
> >
> > if (true) {
> > return;
> > }
> >
> > var bar = function() {
> > };
> >
> > foo();
> > })();
> >
> > Suddenly your variable does become global. JSLint recommends you define
> all
> > your variables at the top of each scope, so this kind of thing won't
> happen.
>
> Erm, I don't see it. What becomes global then?
>
> You're right, I need more coffee. It becomes undefined due to hoisting, but
beyond confusing if you have it also defined in the global scope.


[Non-text portions of this message have been removed]

I'm a little confused about something that is pretty fundamental in
JavaScript. I was thinking that Object is a prototype of every object.
That doesn't seem to be the case though. For example, the following
code prints "false".

var obj = {};
print(Object.isPrototypeOf(obj));

So every object has the methods of Object, but there doesn't seem to
be a reflective way to see how that happens.

Likewise, I think of all the wrapper classes like Boolean, Number and
String as "inheriting" from Object, but I can't verify that with code.

Can someone set me straight?

--
R. Mark Volkmann
Object Computing, Inc.

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> I'm a little confused about something that is pretty fundamental in
> JavaScript. I was thinking that Object is a prototype of every object.
> That doesn't seem to be the case though. For example, the following
> code prints "false".
>
> var obj = {};
> print(Object.isPrototypeOf(obj));
>
> So every object has the methods of Object, but there doesn't seem to
> be a reflective way to see how that happens.
>
> Likewise, I think of all the wrapper classes like Boolean, Number and
> String as "inheriting" from Object, but I can't verify that with code.

{} inherits from Object.prototype.

Object inherits from Function.prototype because it is a function.

A string inherits from String.prototype, which inherits from Object.prototype.

On Thu, Jul 29, 2010 at 3:50 PM, Douglas Crockford
<douglas@...>wrote:

>  --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Mark
> Volkmann <r.mark.volkmann@...> wrote:
> >
> > I'm a little confused about something that is pretty fundamental in
> > JavaScript. I was thinking that Object is a prototype of every object.
> > That doesn't seem to be the case though. For example, the following
> > code prints "false".
> >
> > var obj = {};
> > print(Object.isPrototypeOf(obj));
> >
> > So every object has the methods of Object, but there doesn't seem to
> > be a reflective way to see how that happens.
> >
> > Likewise, I think of all the wrapper classes like Boolean, Number and
> > String as "inheriting" from Object, but I can't verify that with code.
>
> {} inherits from Object.prototype.
>
> Object inherits from Function.prototype because it is a function.
>
> A string inherits from String.prototype, which inherits from
> Object.prototype.
>

Thank you very much! That helped a lot!

Can someone explain why the second line below outputs false?
I thought since the first line outputs true, the second would also.

print(Object.prototype.isPrototypeOf(String.prototype)); // true
print(String.prototype.prototype === Object.prototype); // false; Why?

--
R. Mark Volkmann
Object Computing, Inc.


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> On Thu, Jul 29, 2010 at 3:50 PM, Douglas Crockford
> <douglas@...>wrote:
>
> >  --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Mark
> > Volkmann <r.mark.volkmann@> wrote:
> > >
> > > I'm a little confused about something that is pretty fundamental in
> > > JavaScript. I was thinking that Object is a prototype of every object.
> > > That doesn't seem to be the case though. For example, the following
> > > code prints "false".
> > >
> > > var obj = {};
> > > print(Object.isPrototypeOf(obj));
> > >
> > > So every object has the methods of Object, but there doesn't seem to
> > > be a reflective way to see how that happens.
> > >
> > > Likewise, I think of all the wrapper classes like Boolean, Number and
> > > String as "inheriting" from Object, but I can't verify that with code.
> >
> > {} inherits from Object.prototype.
> >
> > Object inherits from Function.prototype because it is a function.
> >
> > A string inherits from String.prototype, which inherits from
> > Object.prototype.
> >
>
> Thank you very much! That helped a lot!
>
> Can someone explain why the second line below outputs false?
> I thought since the first line outputs true, the second would also.
>
> print(Object.prototype.isPrototypeOf(String.prototype)); // true
> print(String.prototype.prototype === Object.prototype); // false; Why?

prototype is a property of a constructor function, it is not the property
through which an object delegates to another object, which is the key to
inheritance. In some implementations, the delegation property is surfaced as
__proto__, which is distinct from prototype.

String.prototype is an object containing string methods. It is not a function,
so it is likely that it does not have a .prototype property.

String is a function, so it inherits from Function.prototype. String also has a
prototype property containing string methods.

The new operator makes a new object that inherits from the prototype property of
a constructor function. I do not recommend use of the new operator.

2010/7/30 Douglas Crockford <douglas@...>
(...)

> The new operator makes a new object that inherits from the prototype
> property of a constructor function. I do not recommend use of the new
> operator.
>
(...)

Why not Doug?

also, in order do emulate classes i've been using closures like this:

function ClassX(a,b){

   this.method=function(x){
      //...
   }
   //...
}


and in order do emulate inheritance, i'm using some call methods:

function ClassY(w){

   ClassX.call(this,2,w);
   //...
}

in this way which features do i lose?

sorry for thread kindap and thanks for any advice.


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Leonardo <sombriks@...> wrote:
>
> 2010/7/30 Douglas Crockford <douglas@...>
> (...)
>
> > The new operator makes a new object that inherits from the prototype
> > property of a constructor function. I do not recommend use of the new
> > operator.
> >
> (...)
>
> Why not Doug?

Read this: http://www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwideweb

I grabbed a copy of arrayextras.js from
http://erik.eae.net/archives/2005/06/05/17.53.19/ so I could use the
new ECMAScript 5 Array methods in ECMAScript 3 environments. Is there
a more recommended implementation of those methods I should grab from
somewhere else?

--
R. Mark Volkmann
Object Computing, Inc.

On Fri, Jul 30, 2010 at 3:49 PM, Douglas Crockford <douglas@...>wrote:

>  > Can someone explain why the second line below outputs false?
> > I thought since the first line outputs true, the second would also.
> >
> > print(Object.prototype.isPrototypeOf(String.prototype)); // true
> > print(String.prototype.prototype === Object.prototype); // false; Why?
>
> prototype is a property of a constructor function, it is not the property
> through which an object delegates to another object, which is the key to
> inheritance. In some implementations, the delegation property is surfaced as
> __proto__, which is distinct from prototype.
>

Thanks for explaining that! I think I've almost connected all the dots.

function Foo() {}
var foo = new Foo();

All of these line print "true" in Rhino:

print(foo.constructor === Foo);
print(Foo.constructor === Function);
print(Function.prototype.isPrototypeOf(Foo));
print(Object.prototype.isPrototypeOf(Function.prototype));
print(Foo.constructor.prototype === Function.prototype);

Can someone explain why the last two lines print "false"?

print(Function.constructor.prototype === Object.prototype);
print(Function.constructor === Object);

Maybe my assumption that all function objects inherit from Object.prototype
is wrong.

--
R. Mark Volkmann
Object Computing, Inc.


[Non-text portions of this message have been removed]

> print(Function.constructor.prototype === Object.prototype);

I dunno about Rhino, but in Chrome, Function.constructor.prototype is actually a
function, that is constructed by Function.

Try this:

print(Function.constructor === Function.constructor.prototype.constructor);


> print(Function.constructor === Object);

At least in Chrome, Function's constructor is Function. Fun bit of recursion.

Try this:

print(Function.constructor === Function);


I have no clue how the JavaScript interpreter handles that kind of infinite
recursion, but it does.

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> On Fri, Jul 30, 2010 at 3:49 PM, Douglas Crockford <douglas@...>wrote:
>
> >  > Can someone explain why the second line below outputs false?
> > > I thought since the first line outputs true, the second would also.
> > >
> > > print(Object.prototype.isPrototypeOf(String.prototype)); // true
> > > print(String.prototype.prototype === Object.prototype); // false; Why?
> >
> > prototype is a property of a constructor function, it is not the property
> > through which an object delegates to another object, which is the key to
> > inheritance. In some implementations, the delegation property is surfaced as
> > __proto__, which is distinct from prototype.
> >
>
> Thanks for explaining that! I think I've almost connected all the dots.
>
> function Foo() {}
> var foo = new Foo();
>
> All of these line print "true" in Rhino:
>
> print(foo.constructor === Foo);
> print(Foo.constructor === Function);
> print(Function.prototype.isPrototypeOf(Foo));
> print(Object.prototype.isPrototypeOf(Function.prototype));
> print(Foo.constructor.prototype === Function.prototype);
>
> Can someone explain why the last two lines print "false"?
>
> print(Function.constructor.prototype === Object.prototype);
> print(Function.constructor === Object);
>
> Maybe my assumption that all function objects inherit from Object.prototype
> is wrong.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
> [Non-text portions of this message have been removed]
>

Just learned something new! This works in Rhino 1.7. See the line with
the comment below.

function assert(condition) {
   if (!condition) print('assertion failed'));
}

function getValues() {
   return ['text', 19, true];
}

var [s, n, b] = getValues(); // Array destructuring!

assert(s === 'text');
assert(n === 19);
assert(b);

I can't find this in the ECMAScript 3 spec. Is this a standard
JavaScript feature?

--
R. Mark Volkmann
Object Computing, Inc.

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> Just learned something new! This works in Rhino 1.7. See the line with
> the comment below.
>
> function assert(condition) {
>   if (!condition) print('assertion failed'));
> }
>
> function getValues() {
>   return ['text', 19, true];
> }
>
> var [s, n, b] = getValues(); // Array destructuring!
>
> assert(s === 'text');
> assert(n === 19);
> assert(b);
>
> I can't find this in the ECMAScript 3 spec. Is this a standard
> JavaScript feature?

No, which is why you should avoid it.

I put a small shim in the JSLint Rhino edition to make it run identically on
node.js:

http://github.com/tsmith/jslint-node-edition

With this you can run JSLint by:

node jslint.js [file to check]

Which will display the full output of JSLint as on Rhino, including all the
style checks.

As Described in ECMA-262 3rd Edition JSLint fails to support Rules for Variable
names as laid out in section 7.3 on page 14-15 where...

Identifier ::
IdentifierName but not ReservedWord

IdentifierName ::
IdentifierStart
IdentifierName IdentifierPart

IdentifierStart ::
UnicodeLetter
$
_
\ UnicodeEscapeSequence

IdentifierPart ::
IdentifierStart
UnicodeCombiningMark
UnicodeDigit
UnicodeConnectorPunctuation
\ UnicodeEscapeSequence

UnicodeLetter
any character in the Unicode categories "Uppercase letter (Lu)", "Lowercase
letter (Ll)", "Titlecase letter (Lt)",
"Modifier letter (Lm)", "Other letter (Lo)", or "Letter number (Nl)".
UnicodeCombiningMark
any character in the Unicode categories "Non-spacing mark (Mn)" or "Combining
spacing mark (Mc)"
UnicodeDigit
any character in the Unicode category "Decimal number (Nd)"
UnicodeConnectorPunctuation
any character in the Unicode category "Connector punctuation (Pc)"
UnicodeEscapeSequence
see 7.8.4.

fails to support any or \ UnicodeEscapeSequence, UnicodeLetter,
UnicodeCombiningMark when present in identifier names.
while for English these may not be the most desired, it should still be support
as it is legitimate and in for those who are non english speakers usage of
unicode characters would be normal to reflect their language.