Don't Restrict NewExpression to Identifier

[jshint]

Don't Restrict NewExpression to Identifier

[Raynos]

The reason it says that is because the usage of the new keyword has been limited to

new SomeConstructor();

new SomeConstructor; or
new function() { };

Are both considered weird and "doing it wrong". This is part of the JSLint from crockford.

Imho anonymous function constructors is an abuse of the language and should be re factored.

[GarrettS]

The first "bad" pattern has no negative consequential effect. Belief that it is "wrong" usually comes from those who are not accustomed to that as being "normal". The other misthinking is that it must be an error becuase the call operator is not used. That is wrong because there is no call operator; it is new that results in [[Construct]]. See also: http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/6bb13a70aa769e17/282acf2360d8a4ac

And so there is no harm in, for example: new Date;

The second production is useful for creating a singleton:

var mySingleton = new function() {
  var secret = 1234; 
  this.getSecret = getSecret;
  function getSecret() { /* ... */ };
  };

Other alternatives to this pattern may work fine. But that does not make this pattern inherently wrong. It can actually work fine. See also: http://www.highdots.com/forums/javascript/using-new-function-singleton-298119.html

A

[GarrettS]

Whoops, should have been 'function getSecret() { /* ... */ }'

[Raynos]

the anonymous function constructor is easy to abuse and most of the time there is a better alternative pattern.

I personally find that it hinders readability more then it helps for non-trivial code snippets. It'd highly advice against it.

I do agree on the first matter I quite like new Constructor; without the use of ().

There probably should be a flag along the lines of "tolerate weird constructors"

[GarrettS]

You said that most of the time there is a better pattern -- I agree. However using anonymous function in new expression is desirable for a few reasons mentioned in that thread I linked. I suggest reading that through to see others' perspective (though DM goes off the deep end (as usual)).

It's less common, but not weird -- perfectly normal to want to use that sometimes. Am I wrong, here:
https://github.com/GarrettS/ape-javascript-library/blob/master/src/anim/Animation.js#L306

[Raynos]

Personally that makes me go wtf. I'd prefer the significantly more readable

manager = (function() {
    ...
    return {
        "register": register,
        "unregister": unregister
    };
}());

The worst thing is that you used a pascal case name to suggest a constuctor and then marked as @class when it's clearly an object and not a constructor.

[GarrettS]

I see your point about using lower case. And I totally agree about the comments. Most of my more recent code does not sue comments at all.

Using new function() { } is still legit. It's clear that the result of that must be an object. And if it makes you curse, even better .

[Raynos]

The reason everyone prefers the (function() { ... return { ... }; } over new function() { } is that the latter is slower

[GarrettS]

This is an op that is run once. I don't agree on the performance reason here. And I believe that the reason JSLint (original) disallowed this was that it was a "weird construct" or something.

I left a comment there regarding using ReservedWord for Identifier but in browsers where it works, performance outcomes vary.

And performance outcomes cannot be expected. AYCS, the results vary depending on browser. Looks like new function(){}; is faster in somebody's "Chrome 11.0.672".

I think a better argument is whether or not it is a weird construct or what that means or what is wrong with new function(){}.

[Raynos]

I'm going to have to agree with you that both uses are valid. The new operator should not through a weird construct warning for either:

new Foo; or

new function() { ... };

The former error is caused here. this should simply be fixed by removing the check.

Where as the latter error orginates from this. I think this is caused by the !== "function" check. If you remove this your going to have to add more logic to start parsing a function definition.

[valueof]

Since new Foo; might as well be a typo by default JSHint will not tolerate neither that nor new with anonymous functions. However, I made an opt-in option supernew that disables those checks.