basic Q

[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 ?

[Richard Cornford]

Re: basic Q

Boobie wrote:[color=blue]
> var myString = new String("Hello world") ;
> var myString = "Hello world" ;
>
> There is NO difference between the two right ?[/color]

Yes there is.
[color=blue]
> both creates a String obj right ?[/color]

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.

[Kevin Newman]

Re: basic Q

Richard Cornford wrote:[color=blue]
> Boobie wrote:
>[color=green]
>>var myString = new String("Hello world") ;
>>var myString = "Hello world" ;
>>
>>There is NO difference between the two right ?[/color]
>
>
> Yes there is.
>
>[color=green]
>>both creates a String obj right ?[/color]
>
>
> 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.
>
>[/color]

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.

[Boobie]

Re: basic Q


"Richard Cornford"[color=blue]
> 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.[/color]

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

[Kevin Newman]

Re: basic Q

Richard Cornford wrote:[color=blue]
> Boobie wrote:[color=green]
>> var myString = new String("Hello world") ;
>> var myString = "Hello world" ;
>>[/color]
>
> 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.[/color]

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.

[Boobie]

Re: basic Q

"Boobie"[color=blue]
> var myString = new String("Hello world") ;
> var myString = "Hello world" ;
>
> There is NO difference between the two right ? both creates a String obj
> right ?
>[/color]

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' ;

[Richard Cornford]

Re: basic Q

Boobie wrote:[color=blue]
> "Richard Cornford"[color=green]
>> 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.[/color]
>
> thanks
> so when (under what circumstances) would you use one form
> vs the other ?[/color]

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

Richard.

[Richard Cornford]

Re: basic Q

Kevin Newman wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Boobie wrote:[color=darkred]
>>> var myString = new String("Hello world") ;
>>> var myString = "Hello world" ;[/color]
>>
>> 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.[/color]
>
> Does this have an impact on how each is passed (by
> reference or by copy)?[/color]

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
indistinguishab le 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 .
[color=blue]
> Is there any documentation on the way that javascript handles
> passing variables?[/color]

See:- ECMA 262, 3rd edition; Sections 10.2 and 11.2.4 - for the defined
behaviour.
[color=blue]
> 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?[/color]

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.

[Richard Cornford]

Re: basic Q

Kevin Newman wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Boobie wrote:[color=darkred]
>>>var myString = new String("Hello world") ;
>>>var myString = "Hello world" ;
>>>
>>>There is NO difference between the two right ?[/color]
>>
>> Yes there is.
>>[color=darkred]
>>>both creates a String obj right ?[/color]
>>
>> 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.
>>[/color]
> What does that mean in practice?[/color]

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.someth ing = 'any value';
alert(myString. something); //alerts "any value".

- while:-

var myString = "Hello world" ;
myString.someth ing = '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.someth ing -
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.
[color=blue]
> Is there a performance consideration?[/color]

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).
[color=blue]
> Also, when you use the first method (new String('Hello World')),
> does that create a string primitive that is passed to the String
> constructor,[/color]

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).
[color=blue]
> there by actually creating two objects (even if the
> primitive is only temporary (if it is))?[/color]

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.

[RobG]

Re: basic Q

Boobie wrote:[color=blue]
> "Boobie"
>[color=green]
>>var myString = new String("Hello world") ;
>>var myString = "Hello world" ;
>>
>>There is NO difference between the two right ? both creates a String obj
>>right ?
>>[/color]
>
>
> 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' ;[/color]

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

[Kevin Newman]

Re: basic Q

Richard Cornford wrote:[color=blue]
> Kevin Newman wrote:[color=green]
>> Richard Cornford wrote:[color=darkred]
>>> 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.
>>>[/color]
>> What does that mean in practice?[/color]
>
> 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.someth ing = 'any value';
> alert(myString. something); //alerts "any value".
>
> - while:-
>
> var myString = "Hello world" ;
> myString.someth ing = '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.someth ing -
> 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.
>[color=green]
>> Is there a performance consideration?[/color]
>
> 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).
>[color=green]
>> Also, when you use the first method (new String('Hello World')),
>> does that create a string primitive that is passed to the String
>> constructor,[/color]
>
> 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).
>[color=green]
>> there by actually creating two objects (even if the
>> primitive is only temporary (if it is))?[/color]
>
> 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.
>
>[/color]


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

Kevin N.