469,917 Members | 1,873 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,917 developers. It's quick & easy.

basic Q

var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ? both creates a String obj
right ?
Sep 12 '05 #1
10 1351
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ?
Yes there is.
both creates a String obj right ?


The first creates a String object and assigns a reference to that object
to a variable, the second assigns a string primitive value to a
variable.

Richard.
Sep 12 '05 #2
Richard Cornford wrote:
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ?

Yes there is.

both creates a String obj right ?

The first creates a String object and assigns a reference to that object
to a variable, the second assigns a string primitive value to a
variable.

Richard.


What does that mean in practice? Is there a performance consideration?

Also, when you use the first method (new String('Hello World')), does
that create a string primitive that is passed to the String constructor,
there by actually creating two objects (even if the primitive is only
temporary (if it is))?

Kevin N.
Sep 12 '05 #3

"Richard Cornford"
The first creates a String object and assigns a reference to that object
to a variable, the second assigns a string primitive value to a
variable.


thanks
so when (under what circumstances) would you use one form vs the other ?
Sep 12 '05 #4
Richard Cornford wrote:
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;


The first creates a String object and assigns a reference to that object
to a variable, the second assigns a string primitive value to a
variable.


Does this have an impact on how each is passed (by reference or by copy)?

Is there any documentation on the way that javascript handles passing
variables?

This was an issue when php 5.x was release, as they changed the way all
objects are passed (so they are now passed by reference instead of being
copied). PHP provides ways to force passing by reference or copy. Is
there a way to do that in javascript?

Thanks,

Kevin N.
Sep 12 '05 #5
"Boobie"
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ? both creates a String obj
right ?


One thing I found just now is that with the first declaration,
you can do this OO-type of thing :

var myString = new String("Hello world") ;
myString.crap = 'foobar' ;
Sep 12 '05 #6
Boobie wrote:
"Richard Cornford"
The first creates a String object and assigns a reference
to that object to a variable, the second assigns a string
primitive value to a variable.


thanks
so when (under what circumstances) would you use one form
vs the other ?


I would only create a String Object if I had a reason to create a String
Object.

Richard.
Sep 12 '05 #7
Kevin Newman wrote:
Richard Cornford wrote:
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;
The first creates a String object and assigns a reference
to that object to a variable, the second assigns a string
primitive value to a variable.


Does this have an impact on how each is passed (by
reference or by copy)?


You can successfully think of javascript/ECMAScript passing primitives
by value and objects by reference (much like Java). However, ECMAScript
is defined in terms of its behaviour and not in terms of any specific
implementation/ implementation strategy. So whatever an implementation
actually does is not important so long as it cannot be observed to
differ in its behaviour from how ECMA 262 says it should behave. The
handling of function arguments is described entry in terms of actual
values being assigned to properties of objects (the Variable/Activation
object). There is nothing to indicate whether these values are copies of
the values resolved as function arguments, and indeed there is nothing
specifying the actual nature of a primitive value. There is an internal
Reference type that is the result of resolving expression that refer to
objects, but that just means that passing an object by reference is
indistinguishable from passing the Reference type by value.

It is interesting to note that the only way of changing the value of a
variable/property is by assigning a new value to it (assignment is
internal and implicit with pre and post decrement/increment operators).
This means that all primitive value can be immutable, changed by
assigning other immutable values. This means that all primitive values
could be implemented as references to immutable objects, and so passing
by value may actually involve passing references to these internal
implementation objects.

The source code and documentation for open source implementation should
show what actually happens in those implementations, but is no general
guide to all ECMAScript implementations.
Is there any documentation on the way that javascript handles
passing variables?
See:- ECMA 262, 3rd edition; Sections 10.2 and 11.2.4 - for the defined
behaviour.
This was an issue when php 5.x was release, as they changed
the way all objects are passed (so they are now passed by
reference instead of being copied). PHP provides ways to
force passing by reference or copy. Is there a way to do
that in javascript?


Not defined in the language, though most things can be implemented if
they are seen to be important. Passing objects by reference is not that
much of a problem once you are expecting it.

Richard.
Sep 12 '05 #8
Kevin Newman wrote:
Richard Cornford wrote:
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ?
Yes there is.
both creates a String obj right ?


The first creates a String object and assigns a reference to that
object to a variable, the second assigns a string primitive value to
a variable.

What does that mean in practice?


All objects type-convert to boolean true, only non-empty string
primitives type-convert to boolean true. String objects have
String methods, string primitives must be type-converted into
String objects before string methods can be called upon them
(the type-conversion to object is implicit when a primitive
appears in a context that requires an object, such as in a
member expression).

As objects, String objects may have arbitrary named properties
added (and values assigned) to then at runtime. So:-

var myString = new String("Hello world")
myString.something = 'any value';
alert(myString.something); //alerts "any value".

- while:-

var myString = "Hello world" ;
myString.something = 'any value';
alert(myString.something); //alerts "undefined".

- because in the second case myStirng is internally type-converted
into a String object for the resolution of the assignment
expression (so it would not be expected to error) but that String
Object does not replace the value assigned to myStirng, and
myString is again type-converted into another String object for
the resolution of the property accessor - myString.something -
in the - alert - call.

In the first case the myString object is assigned a new property
and when it is read back in the alert it is the same string object
that is having its property read.
Is there a performance consideration?
If a string primitive value was to be subject to repeated uses
of String methods then it would be theoretically more efficient
to first make a String object representation of it and call the
string methods on that one object, avoiding repeated implicit
type-conversion. However, this is such a common requirement that
implementations appear to be heavily optimized in this direction
so performance gains may not be significant (or even noticeable).
Also, when you use the first method (new String('Hello World')),
does that create a string primitive that is passed to the String
constructor,
A string primitive is passed to the constructor, but in ECMAScript
terms there are no grounds for believing that the string primitive
is created at that point. It may have existed in its final,
immutable form since the tokenizing of the original source code
(StringLiteral is an ECMAScript lexical token).
there by actually creating two objects (even if the
primitive is only temporary (if it is))?


While the odds are good that the representation if the string
primitive used by the interpreter can be reasonably be described
as an object it is not an Object in the sense that the term is
used in ECMAScript. Thus they may both be objects if you are
programming an ECMAScript interpreter but only the String Object
is an Object if you are writing ECMAScript.

If anything the string primitive may be longer lived than
the String Object. If this code was inside a function body
it may be precisely the same representation of the string
primitive that was used whenever the function was called,
but a new and distinct String Object would be created with
each function call, and if freed it may be garbage collected
before the representation of the string primitive was finished
with.

Richard.
Sep 12 '05 #9
Boobie wrote:
"Boobie"
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ? both creates a String obj
right ?

One thing I found just now is that with the first declaration,
you can do this OO-type of thing :

var myString = new String("Hello world") ;
myString.crap = 'foobar' ;


Using new String() creates a string object that can have properties
assigned to it.

In the example above, a string object is created and given a property
called 'crap' which is then assigned the string literal 'foobar' as its
value.
--
Rob
Sep 12 '05 #10
Richard Cornford wrote:
Kevin Newman wrote:
Richard Cornford wrote:
Boobie wrote:
var myString = new String("Hello world") ;
var myString = "Hello world" ;

There is NO difference between the two right ?
Yes there is.

both creates a String obj right ?
The first creates a String object and assigns a reference to that
object to a variable, the second assigns a string primitive value to
a variable.

What does that mean in practice?


All objects type-convert to boolean true, only non-empty string
primitives type-convert to boolean true. String objects have
String methods, string primitives must be type-converted into
String objects before string methods can be called upon them
(the type-conversion to object is implicit when a primitive
appears in a context that requires an object, such as in a
member expression).

As objects, String objects may have arbitrary named properties
added (and values assigned) to then at runtime. So:-

var myString = new String("Hello world")
myString.something = 'any value';
alert(myString.something); //alerts "any value".

- while:-

var myString = "Hello world" ;
myString.something = 'any value';
alert(myString.something); //alerts "undefined".

- because in the second case myStirng is internally type-converted
into a String object for the resolution of the assignment
expression (so it would not be expected to error) but that String
Object does not replace the value assigned to myStirng, and
myString is again type-converted into another String object for
the resolution of the property accessor - myString.something -
in the - alert - call.

In the first case the myString object is assigned a new property
and when it is read back in the alert it is the same string object
that is having its property read.
Is there a performance consideration?


If a string primitive value was to be subject to repeated uses
of String methods then it would be theoretically more efficient
to first make a String object representation of it and call the
string methods on that one object, avoiding repeated implicit
type-conversion. However, this is such a common requirement that
implementations appear to be heavily optimized in this direction
so performance gains may not be significant (or even noticeable).
Also, when you use the first method (new String('Hello World')),
does that create a string primitive that is passed to the String
constructor,


A string primitive is passed to the constructor, but in ECMAScript
terms there are no grounds for believing that the string primitive
is created at that point. It may have existed in its final,
immutable form since the tokenizing of the original source code
(StringLiteral is an ECMAScript lexical token).
there by actually creating two objects (even if the
primitive is only temporary (if it is))?


While the odds are good that the representation if the string
primitive used by the interpreter can be reasonably be described
as an object it is not an Object in the sense that the term is
used in ECMAScript. Thus they may both be objects if you are
programming an ECMAScript interpreter but only the String Object
is an Object if you are writing ECMAScript.

If anything the string primitive may be longer lived than
the String Object. If this code was inside a function body
it may be precisely the same representation of the string
primitive that was used whenever the function was called,
but a new and distinct String Object would be created with
each function call, and if freed it may be garbage collected
before the representation of the string primitive was finished
with.

Richard.

That was great! Thanks for the excellent info. :-)

Kevin N.

Sep 13 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Michael Foord | last post: by
9 posts views Thread by Malcolm | last post: by
56 posts views Thread by Dave Vandervies | last post: by
14 posts views Thread by luis | last post: by
3 posts views Thread by sefe dery | last post: by
10 posts views Thread by trippeer | last post: by
97 posts views Thread by Master Programmer | last post: by
6 posts views Thread by Simon Walsh | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.