We Keep Coding

Javascript - primitive string implicit conversion to object

I will reference to Mozilla's docs about String object.
JavaScript automatically converts primitives to String objects, so that it's possible to use String object methods for primitive strings. In contexts where a method is to be invoked on a primitive string or a property lookup occurs, JavaScript will automatically wrap the string primitive and call the method or perform the property lookup.
Good example of such situation would be accessing length property:
let word = "Hello";
word.length;
I have understood that what happens in this situation is:
let word = "Hello";
String(word).length;
But after trying some benchmarks it's clear for me that word.length is much faster than String(word).length. It seems that implicit conversion is something completely different than String(word), much faster. I cannot find any info about how this implicit conversion works, but it might be helpful to know in some optimization problems.

The reason for that is probably time to parse and the fact that inner JS string object (that is actually C++) works faster then creating extra interface to interact with string on high JS level...
So it's all about optimisation
There is good article about it (https://dev.to/promhize/what-you-need-to-know-about-javascripts-implicit-coercion-e23).

Why are Strings and Numbers in JS considered immutable? [duplicate]

If a string is immutable, does that mean that....
(let's assume JavaScript)
var str = 'foo';
alert(str.substr(1)); // oo
alert(str); // foo
Does it mean, when calling methods on a string, it will return the modified string, but it won't change the initial string?
If the string was mutable, does that mean the 2nd alert() would return oo as well?

It means that once you instantiate the object, you can't change its properties. In your first alert you aren't changing foo. You're creating a new string. This is why in your second alert it will show "foo" instead of oo.
Does it mean, when calling methods on
a string, it will return the modified
string, but it won't change the
initial string?
Yes. Nothing can change the string once it is created. Now this doesn't mean that you can't assign a new string object to the str variable. You just can't change the current object that str references.
If the string was mutable, does that
mean the 2nd alert() would return oo
as well?
Technically, no, because the substring method returns a new string. Making an object mutable, wouldn't change the method. Making it mutable means that technically, you could make it so that substring would change the original string instead of creating a new one.

On a lower level, immutability means that the memory the string is stored in will not be modified. Once you create a string "foo", some memory is allocated to store the value "foo". This memory will not be altered. If you modify the string with, say, substr(1), a new string is created and a different part of memory is allocated which will store "oo". Now you have two strings in memory, "foo" and "oo". Even if you're not going to use "foo" anymore, it'll stick around until it's garbage collected.
One reason why string operations are comparatively expensive.

Immutable means that which cannot be changed or modified.
So when you assign a value to a string, this value is created from scratch as opposed to being replaced. So everytime a new value is assigned to the same string, a copy is created. So in reality, you are never changing the original value.

I'm not certain about JavaScript, but in Java, strings take an additional step to immutability, with the "String Constant Pool". Strings can be constructed with string literals ("foo") or with a String class constructor. Strings constructed with string literals are a part of the String Constant Pool, and the same string literal will always be the same memory address from the pool.
Example:
String lit1 = "foo";
String lit2 = "foo";
String cons = new String("foo");
System.out.println(lit1 == lit2); // true
System.out.println(lit1 == cons); // false
System.out.println(lit1.equals(cons)); // true
In the above, both lit1 and lit2 are constructed using the same string literal, so they're pointing at the same memory address; lit1 == lit2 results in true, because they are exactly the same object.
However, cons is constructed using the class constructor. Although the parameter is the same string constant, the constructor allocates new memory for cons, meaning cons is not the same object as lit1 and lit2, despite containing the same data.
Of course, since the three strings all contain the same character data, using the equals method will return true.
(Both types of string construction are immutable, of course)

The text-book definition of mutability is liable or subject to change or alteration.
In programming, we use the word to mean objects whose state is allowed to change over time. An immutable value is the exact opposite – after it has been created, it can never change.
If this seems strange, allow me to remind you that many of the values we use all the time are in fact immutable.
var statement = "I am an immutable value";
var otherStr = statement.slice(8, 17);
I think no one will be surprised to learn that the second line in no way changes the string in statement.
In fact, no string methods change the string they operate on, they all return new strings. The reason is that strings are immutable – they cannot change, we can only ever make new strings.
Strings are not the only immutable values built into JavaScript. Numbers are immutable too. Can you even imagine an environment where evaluating the expression 2 + 3 changes the meaning of the number 2? It sounds absurd, yet we do this with our objects and arrays all the time.

Immutable means the value can not be changed. Once created a string object can not be modified as its immutable. If you request a substring of a string a new String with the requested part is created.
Using StringBuffer while manipulating Strings instead makes the operation more efficient as StringBuffer stores the string in a character array with variables to hold the capacity of the character array and the length of the array(String in a char array form)

From strings to stacks... a simple to understand example taken from Eric Lippert's blog:
Path Finding Using A* in C# 3.0, Part Two...
A mutable stack like System.Collections.Generic.Stack
is clearly not suitable. We want to be
able to take an existing path and
create new paths from it for all of
the neighbours of its last element,
but pushing a new node onto the
standard stack modifies the stack.
We’d have to make copies of the stack
before pushing it, which is silly
because then we’d be duplicating all
of its contents unnecessarily.
Immutable stacks do not have this problem. Pushing onto an immutable
stack merely creates a brand-new stack
which links to the old one as its
tail. Since the stack is immutable,
there is no danger of some other code
coming along and messing with the tail
contents. You can keep on using the
old stack to your heart’s content.
To go deep on understaning immutability, read Eric's posts starting with this one:
Immutability in C# Part One: Kinds of Immutability

One way to get a grasp of this concept is to look at how javascript treats all objects, which is by reference. Meaning that all objects are mutable after being instantiated, this means that you can add an object with new methods and properties. This matters because if you want an object to be immutable the object can not change after being instantiated.

Try This :
let string = "name";
string[0] = "N";
console.log(string); // name not Name
string = "Name";
console.log(string); // Name
So what that means is that string is immutable but not constant, in simple words re-assignment can take place but can not mutate some part.

The text-book definition of mutability is liable or subject to change or alteration. In programming, we use the word to mean objects whose state is allowed to change over time. An immutable value is the exact opposite – after it has been created, it can never change.
If this seems strange, allow me to remind you that many of the values we use all the time are in fact immutable.
var statement = "I am an immutable value"; var otherStr = statement.slice(8, 17);
I think no one will be surprised to learn that the second line in no way changes the string in statement. In fact, no string methods change the string they operate on, they all return new strings. The reason is that strings are immutable – they cannot change, we can only ever make new strings.
Strings are not the only immutable values built into JavaScript. Numbers are immutable too. Can you even imagine an environment where evaluating the expression 2 + 3 changes the meaning of the number 2? It sounds absurd, yet we do this with our objects and arrays all the time.

Javascript strings are primitive types?

In Javascript numbers strings and booleans are said to be primitive types.
Primitive types are passed around by copy.
OK consider the following code:
var s1 = "this is a string of 1000 characters ...";
var s2 = s1; // (2)
What happens in line (2)? 1000 characters are copied to the variable s2?
OR is there one memory location and both s1 and s2 refer to this memory location?
I believe the second is true.
If so, why all books say that strings are primitive types, they are not, they are
reference types, aren't they?

What happens in line (2)? 1000 characters are copied to the variable s2? OR is there one memory location and both s1 and s2 refer to this memory location?
It is an implementation detail of the JavaScript engine, there is no way to tell the difference from inside the JavaScript program.
why all books say that strings are primitive types
The language defines them as such.
they are reference types, aren't they?
They might be implemented that way at a level lower then is exposed to JS, but that doesn't matter to the JS author.

What happens in line (2)?
That's more or less implementation defined. To you, it will look like a copy. However, the engine is free to optimise it, and probably will. No doubt, something like copy-on-write.
In JavaScript, there are primitive strings and string objects. It's worth knowing the differences. A string object is passed around by reference, but seeing as all string methods return a new string, you're unlikely to modify it.

Do we get a speed advantage with: new String("a string") for multiple tests on that string in javaScript

I am making a small search engine where string are searched often. Since javaScript convert a string primitive (declared like var thatString = "a string") to an object when we use methods like indexOf on them, and then back to a primitive, I think that converting all the primitives stings to object with var aString = new String("aString") in the array of strings to be analysed could bring a speed advantage. But is it really worth it ?
The search engine prototype can be seen at http://bottinbio.com and it's code (open source) at http://ogfor.com/bottinbio/code.js

Even when we do not add a property to the string Object made with new String, the primitive is much faster (43-45%) in firefox and chrome in ubuntu.
Thanks DhruvPathak for the link to jsperf.com

JavaScript String as Array: Read but no Write

For JavaScript in most browsers*, you can read a character from a String by treating it like an Array. However, in all the browsers I've tried (IE9, Chrome, Firefox), you can't write to it like an Array.
For example:
var string = 'hello world';
alert(string[0]);//alerts 'h'
alert(string);//alerts 'hello world'
string[0]='j';
alert(string[0]);//alerts 'h'
alert(string);//alerts 'hello world'
This has repercussions for more than just JavaScript developers:
jelloPeople.roam();
Does anybody know the reasoning behind this?
For example, I've looked at Mozilla's documentation, and they allude to it but don't give an explanation:
"..trying to set a character via indexing does not throw an error, but the string itself is unchanged."
Bottom Line: It is strange and confusing to me that some array properties were given to Strings and not others.
UPDATE:
Ok, so JavaScript Strings are immutable objects, but why? It seems like operations such as the above would be faster if they weren't immutable (change 1 character as opposed to making a new 11 character string). In fact, I don't see a case with String functions where performance would be impacted negatively if they weren't immutable, but I see several where performance would be improved. Also, there is no true multi-threading in JavaScript, so no advantage to immutables there.
(removed and will research this and possibly ask in a new quesion)
*Not IE 6 or 7

This simply because javascript strings are immutable by design; once created they cannot be changed.

I think it might be because strings in JavaScript are immutable. Notice that every string function doesn't actually change the string itself, but returns a new one. This is the same for changing characters directly, it wouldn't work with an immutable model.