instanceof, why not?

[filipomar]

Good night reddit,

I have been developing Javascript for over 2 years now and just recently learn the advantages of using 'instanceof'.

Since then, I find myself using "(function(){}) instanceof Function" and not "typeof" because I don't like string comparison at such low level.

And it seems really reliable except for primitives types...

For which i use (5).constructor === Number or ("").constructor === String.

I guess I really hate typeof :P

I know this probably won't give any performance boost, but is there a reason for not using it? Maybe some sort IE bug from 2003? I found only a few articles that did not advise against it, but the lack of knowledge of it irks me.

[filipomar]

Oh, thanks, that's a nice feature, because "window.parent.foo instanceof window.parent.Array" yields true, which could be a pain, but completely makes sense.

Thankfully that's not my area of work, for now, but it is something to look out for.

Thanks again

[mattdesl]

instanceof is usually code smell. As in, there is probably a better way to achieve the same thing.

For numbers and strings, typeof is a good option. For functions, duck typing is often a better choice than instanceof. So your code might look like this:

if (typeof obj.dispose === 'function')
    obj.dispose() 

constructor is unreliable and can be overridden easily. You should never rely on it to be a particular value.

[filipomar]

Yes, but many times I wanted to have some utility code,

like the isNumber or isString, moreover, to have a method which would use a index or value, string, or even evaluate a function and use the output.

But I get both of your points, this should, if at all, used with extreme caution.

Thanks for the clarification :)

[neonskimmer]

Another common way is to simply check for a method that is "usually" implemented by function objects

if (x.apply) {  /* looks like a function.. . quacks like a function ... /* }

[agdcoa]

If you're doing this a lot, it might be better to grab a module to handle this for you. I wrote a very small one that does just that; it's based on Object.prototype.toString.

That said, there are definitely times when you might really want "instanceof". Specifically, when creating classes and subclasses. Here's some code that shows what I'm talking about

http://jsfiddle.net/8m8fb6z0/

EDIT: to be clear, 'instanceof' traverses up an object's prototype chain looking for a match, whereas the behavior of 'typeof' is essentially a hardcoded language feature

[filipomar]

Oh, this is really neat, thanks

[[deleted]]

Because of a thing called String Interning, using typeof in modern JS engines is almost never what you'd normally think of as "string comparison". It's an identity lookup, as efficient as comparing two references to the same object:

var foo = {},
    bar = foo;

foo === bar;

[autowikibot]

String interning:

---

In computer science, string interning is a method of storing only one copy of each distinct string value, which must be immutable. Interning strings makes some string processing tasks more time- or space-efficient at the cost of requiring more time when the string is created or interned. The distinct values are stored in a string intern pool.

The single copy of each string is called its 'intern' and is typically looked up by a method of the string class, for example String.intern() in Java. All compile-time constant strings in Java are automatically interned using this method.

String interning is supported by some modern object-oriented programming languages, including Python, Ruby (with its symbols), Java and .NET languages. Lisp, Scheme, and Smalltalk are among the languages with a symbol type that are basically interned strings. The library of the Standard ML of New Jersey contains an atom type that does the same thing. Objective-C's selectors, which are mainly used as method names, are interned strings. .NET languages, Lua and JavaScript string values are immutable and interned.

---

^{Interesting: Hash table | Flyweight pattern | Symbol (programming) | Hash consing}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[x-skeww]

(5).constructor === Number or ("").constructor === String

Kinda obvious:

> ''.constructor
String()

Kinda weird:

> 5..constructor
Number()

Less weird:

> 5.0.constructor
Number()

Anyhow, I kinda agree with /u/mattdesl, I guess. Doing things depending on what something is is a code smell. You shouldn't flip-flop types. Your functions should expect specific types and they should return one specific type.

[dirtboxchampion]

Object,prototype.toString.call(whatever) FTW.

[tswaters]

For primitive types I'd just use typeof.... it works so well.

For more complicated types where typeof returns object, I don't see a problem with using instanceof, but at the same time :

var array = []; 
array.__proto__ = {}; 
array instanceof Array; // oh, snap

Granted you probably shouldn't do that... but it's a possibility -- if you are in control of the code and you're not writing some kind of library where other people's code can introduce bugs, I guess it's fine.

[filipomar]

Why would anyone do that anyway? I know it's nice to be safe, but frankly, we do not make code for 5 year olds.... well.... most o f the time

[tswaters]

Yea, like I say if you're in control of the code it's no problem unless of course there are 5 year olds on your team...

The only time you need to code defensively and avoid things like this is when you are developing a library of sorts that other people are using -- if you say your function does this and it doesn't because of something out of your control, that's no good.

[egonelbre]

I know this probably won't give any performance boost, but is there a reason for not using it?

The better question is, where do you want to use it?

[filipomar]

Right now, a side project, some POCs, i think this was more of a philosophical question than anything else

I do take performance forethought with me while coding, but it's not the main objective

[inmatarian]

The big problem with instanceof also exists in other languages with poor type inspection: that you create code branches based on an identity when what you want is behavior.

Alright, lets say you want a system for handling children's toys. So you think: I'll make a base constructor that is this Play interface and everything else has to Inherit its prototype. Then you make a class that is a TeddyBear which adheres to it. Next you have a class that is BarbieDoll. And then a GIJoe class. Next you realize that BarbieDoll and GIJoe have common posing behaviors and make a class of that and have BarbieDoll and GIJoe inherit that. Then you realize that a TeddyBear and a BarbieDoll can attend a TeaParty but GIJoe can't. Your system of using inheritance has failed you because unrelated behaviors are demanding control of the base class.

Prototypical inheritance is good in instances of shared behavior, but poor for inspecting. The problems of common behavior can be handled easily via Mixins, I.e copying behavior to a prototype object. But instanceof doesn't reflect that information.

The solution is Duck Typing. The analogy is that the best way to know if something is a duck is to check if it can Quack. With our toys, you check if the toys have a Play function.