What Happens When We Invoke A Method

In ECMAScript 3 up to 5.1, when "use strict" directive is not in place, any primitive value will be temporarily converted into an object, where only null and undefined will be converted into the original global object.

Now you can play adding "use strict" to the very beginning of the whichType function.Doing the same with an argument, rather than context injection, will produce the same output, regardless the function has or not the strict directive.

What If You Want Use new String/Number/Boolean

It's not only about context injection and the typeof this, it's also about the ability to use collections of the same type as we need.As example, let's imagine we have a list of unique IDs, and we would like to flag them, relate them, or use them, as objects.

var ids = [ "a", "b", "c"];

// an easy way to mirror strings as objectsvar flagged = ids.map(Object);

// check if a generic input/id exists ...var i = ids.indexOf("b");

// ... and check if it has been used/touched alreadyif (-1 < i && !flagged[i].touched) { flagged[i].touched = true; alert("touched");}// once again ... but it will never happenif (-1 < i && !flagged[i].touched) { flagged[i].touched = true; alert("touched");}

With above example we might use the variable ids to simply filter existent and not existent input, and mirror these ids through they respective objects and eventually reuse these objects as we need, concatenating them, recycling them, etc etc ... I know, above example is not such common use case, right? But of course it's not since we have so many problems with typeof and nobody in JS world has ever suggested to use, when necessary, these constructors in a useful way...

typeof In JS.Next

Since explicit should superset implicit behaviours, ECMAScript 6 and code under "use strict" directive will react like this.

function app(s) {"use strict"; alert(type.call(s));}

function type() {"use strict"; return typeof this;}

app("primitive"); // "string"app(new String("object"));// "object"

This is actually awesome since we can always tell if that string/object has been created using new Constructor or not ... which leads with less ambiguous code and the possibility to use objects as primitives whenever we find a case were it's needed.

As summary, knowing in advance how an object has been created, will let us understand if whatever property/method changed or attached to a generic this will make sense or not ... unless these operations are not simply used internally during the temporarily lifetime of that possible object ... where again we might need to know if we have to clean up after or not ... that's what I call control, isn't it?

... And No Polyfill Will Do

Bad news here is ... there is no way to replicate the new and correct behaviour of the next typeof operator.If we remove "use strict" directive from the latter example's type() function, we'll notice that the result will be "object" in both cases ... no matter how we pass the original argument.

Reasonable + Inconsistent = Fail

If your only concern is that typeof null should produce the string "null", you might realize that o === null is all you need, rather than creating and calling a function every time you want/need to understand the type of an object.As we have seen before, when null is used as context, the typeof could return "object" in any case.When latter case happens, the check against the triple equality operator will fail as well.If null is not the only problem, just consider that if an engineer created a variable using new String(text) rather than using just text there must be a bloody reason: either the engineer does not know JavaScript OR, most likely, decided to use the possibility offered by an object that is wrapping a primitive value.If you use a framework that does this wrapping by default there's only one thing to do: change framework!Strings are immutable while Objects are always freshly baked ... since a list of strings as objects cannot even use Array#indexOf unless you don't hold and/or compare via Generic#valueOf() every time the list content, the amount of pointless RAM and CPU used to work with these kind of wrappers does not scale ... full stop.If you never use new String and believe that nobody else will as well, your logic might be screwed in any case by the fact that newer browsers might implement a proper typeof and make your code/logic weak when the original constructor has been used as wrapper.

How To Migrate, How To Not Fail

Unless both your code and your environment is frozen by respective versions, and it does not matter if it's client or server side, you cannot basically trust your own code because one day, in some browser, it might act differently.If you need typeof so much and your code is for 3rd parties development, you might decide to create two slightly different versions of your code or simply normalize the old typeof behavior forgetting then returning "string" when you don't actually know if the developer meant string or new String.A feature detection like this one could help:

Above check does not simply tell us if the the browser can handle the strict directive, it also tells us if we are already under use strict.If we wrap everything in our own closure we might not care in any case ... so, back to the topic, we might understand through these checks if we are under strict directive but what we cannot normalize in any case is something like:

In ECMAScript 3rd Edition latest snippet will return "object" while in ES5 and strict directive it will return "string".If your normalizer is "so cool" that transform any instanceof String into "string", then you might realize that same code run under strict in ES5 will return "object" so either both ways, and as summary, your function is not reliable.Can we say now there's more mess than before? Oh well ...

Doesn't Matter, Had Type

If you wanna have a function that will never be able to compete with the real power of ES6 or "use strict"typeof operator, you might end up with something like this:

However, all you gonna have in this case is a function that removes a new feature from the next version of JavaScript.I have aded this script just to give you a chance if you wanna believe that using methods across primitive wrappers does not make sense ( subclassing anybody ? at that point you gonna have another problem ... oh well, again ... )

Andrea, that instanceof solution wouldn´t work with values from another window, would it? Isn´t it the same age old problem as with the non native isArray function? Object.prototype.toString seems to be the only silver bullet proof way but as you say, it´s slow. But working slow beats non working fast.

Pretty great post. I just stumbled upon your weblog and wanted to mention that I've really loved surfing around your weblog posts. In any case I will be subscribing in your rss feed and I'm hoping you write again soon!

thisArg The value of this provided for the call to fun. Note that this may not be the actual value seen by the method: if the method is a function in non-strict mode code, null and undefined will be replaced with the global object, and primitive values will be boxed...

Irishka have you read the post at all or you are just trolling? I wonder if you got what is this post about ... please read again carefully, the fact primitives will be boxed is not new since IE4 ... but thanks ...

P.S. I understand your point about "not being typeof different but the `this` context one" but the problem is that typeof is the only operator able to retrieve the "type" of a variable, as primitive or object.

Since this is the only way to retrieve something like "string" rather than "object" ... using the same code with "use strict" or not, THE SAME CODE, can produce different output THROUGH typeof because of the new ES.Next behavior with objects ... how do you know there is a new behavior and you are in "use strict" ?

Only with typeof operator ... got it? typeof is fine, but being the only thing usable to understand the "type of" is not fine anymore and is NOT SHIMMABLE in ES3 or ES5 without "use strict"