'new' operator for built-in types?

[Daniel Norden]

Hi.

Is it necessary to use the 'new' operator for built-in types like String,
Number, RegExp, .....? The result seems to be the same with or
without 'new'.

For example in a line that looks like this:
s = s.replace(RegExp("\\s*\\b" + name + "\\b\\s*"), " ");


Thanks,
Dano

 

[Lasse Reichstein Nielsen]

Is it necessary to use the 'new' operator for built-in types like String,
Number, RegExp, .....? The result seems to be the same with or
without 'new'.

That depends.

For RegExp and Function, calling it as a function and as a constructor
does the same thing, i.e., creates a new object.

For Date, Object, String, Boolean and Number, calling as a function
doesn't create a new object. Instead the last four perform conversion,
and I don't remember what Date does when called as a function. I have
probably never used it.

For example in a line that looks like this:
s = s.replace(RegExp("\\s*\\b" + name + "\\b\\s*"), " ");

/L

 

[RobG]

Hi.

Is it necessary to use the 'new' operator for built-in types like String,
Number, RegExp, .....? The result seems to be the same with or
without 'new'.

It depends on what you mean by "necessary". Calling String() as a
function does type conversion, calling it as part of a new expression
creates a new object (ECMA-262 Section 15.5.1. & 15.5.2):

var x = String();
var y = new String();
alert( 'x is a ' + typeof x + // String
'\n' + 'y is a ' + typeof y); // Object

For example in a line that looks like this:
s = s.replace(RegExp("\\s*\\b" + name + "\\b\\s*"), " ");

The RegExp function is different, when called as a function it may
behave as if called as part of a new expression, details are in
ECMA-262 Section 15.10.3.

| 15.10.3.1 RegExp(pattern, flags)
| If pattern is an object R whose [[Class]] property
| is "RegExp" and flags is undefined, then return R
| unchanged. Otherwise call the RegExp constructor
| (section 15.10.4.1), passing it the pattern and flags
| arguments and return the object constructed by that constructor.

 

[Daniel Norden]

For RegExp and Function, calling it as a function and as a constructor
does the same thing, i.e., creates a new object.

For Date, Object, String, Boolean and Number, calling as a function
doesn't create a new object. Instead the last four perform conversion,
and I don't remember what Date does when called as a function. I have
probably never used it.

I just checked, Date() returns a timestamp string.
Thanks for the explanation, Lasse.

Dano

 

[Joost Diepenmaat]

Hi.

Is it necessary to use the 'new' operator for built-in types like String,
Number, RegExp, .....? The result seems to be the same with or
without 'new'.

Not for all types, no. See the specs
http://www.ecma-international.org/publications/standards/Ecma-262.htm

The real question should be: do we need the new operator at all?

 

[Daniel Norden]

The RegExp function is different, when called as a function it may
behave as if called as part of a new expression, details are in
ECMA-262 Section 15.10.3.

| 15.10.3.1 RegExp(pattern, flags)
| If pattern is an object R whose [[Class]] property
| is "RegExp" and flags is undefined, then return R
| unchanged. Otherwise call the RegExp constructor
| (section 15.10.4.1), passing it the pattern and flags
| arguments and return the object constructed by that constructor.

Thanks, Rob, very informative.
I'll stick to 'RegExp' instead of 'new RegExp' then.

Dano

 

[David Mark]

The RegExp function is different, when called as a function it may
behave as if called as part of a new expression, details are in
ECMA-262 Section 15.10.3.

| 15.10.3.1 RegExp(pattern, flags)
| If pattern is an object R whose [[Class]] property
| is "RegExp" and flags is undefined, then return R
| unchanged. Otherwise call the RegExp constructor
| (section 15.10.4.1), passing it the pattern and flags
| arguments and return the object constructed by that constructor.

Thanks, Rob, very informative.
I'll stick to 'RegExp' instead of 'new RegExp' then.

Why? It looks like an extra step.

 

[Daniel Norden]

Why? It looks like an extra step.

Maybe, but that's handled by the implementation, and if there's any
performance penalty at all, it's likely negligible compared to the
execution of the regex itself. I guess it's a matter of taste. Leaving
the 'new' out makes the line shorter and (a little) easier to read.

Dano

 

[David Mark]

Maybe, but that's handled by the implementation, and if there's any
performance penalty at all, it's likely negligible compared to the
execution of the regex itself. I guess it's a matter of taste. Leaving
the 'new' out makes the line shorter and (a little) easier to read.

As for being easier to read, it seems like it has the opposite effect.

 

[Thomas 'PointedEars' Lahn]

I just checked, Date() returns a timestamp string.

To be precise, it should return the same as (new Date()).toUTCString() at
the same moment in time. See ECMAScript Edition 3 Final, section 15.9.2.
However, in JavaScript 1.8/Gecko 1.9/Firefox 3 it returns the same as
(new Date()).toString(), which is implementation-dependent.


PointedEars

 

[Thomas 'PointedEars' Lahn]

As for being easier to read, it seems like it has the opposite effect.

Maybe he's used to Python in which case it wouldn't ;-)


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Tue,

Daniel Norden wrote:

To be precise, it should return the same as (new Date()).toUTCString() at
the same moment in time.

It would be naive to rely on it doing that without extensive testing -
if testing in IE7 counts as extensive. To prove, with reasonably
certainty, that they return the same, one also needs to test in multiple
locales. US software writers are likely to be in agreement about how
things are done in the US locale, and even as far away as Canada (PQ
excepted). They are much more likely to provide divergent results for
far away places. But testing in one locale can provide disproof.

See ECMAScript Edition 3 Final, section 15.9.2.

That notwithstanding. Note that .toUTCString() is implementation-
dependent,

However, in JavaScript 1.8/Gecko 1.9/Firefox 3 it returns the same as
(new Date()).toString(), which is implementation-dependent.

IIRC, all direct conversions between Date object and string are
undefined in 16262, and thus are likely to be implementation-dependent,
especially in the forwards direction.