I never realized that typeOf was a JS operator, but it doesn't seem to work the way you have it there. I'd use instanceOf in that case.
I did some timing tests the other day and discovered that instanceOf is 40% faster than using constructor.name -- although, of course, both are very fast, so it hardly amounts to a hill of beans.
Of course, instanceof! Thanks. But typeof is a JS operator, though of limited use, it seems to me, as it distinguishes just string, number, and object:
x = 'abc';
typeof x
returns 'string'. And typeof x == 'string' retrurns true.
I know that instanceof is quicker than constructor.name -- we talked about that here a few months ago. You then decided to stick with constructor.name because instanceof doesn't always work. And as you say, you notice the difference only when constructor.name is called hundreds of times.
There is one very good reason (for me, at least) to not use x.constructor.name.
If you have
function f(){}
x = new f();
everything works as expected (x.constructor.name == 'f).
But if you have:
f = function(){}
x = new f();
x.constructor.name returns 'anonymous' and not 'f'. Using the first form is
usually ok, but if you are send code/data back and forth to Bridge or other
CS2/3 apps, there is no way to force the scope of the function/class to be at
the global level, which you frequently need to do. Using something like
instanceof or a 'typename' property generally works out better as a way of
determining the underlying class in this situation.
and I am getting an object is invalid error. does there have to be a ==
true after instanceof Character
BTW, did you guys know that a character has a different index relative
to the document as opposed to relative to the story? I thought the index
is always counted form the first character in the story and I couldn't
figure out why I was getting the wrong character.
> There is one very good reason (for me, at least) to not use x.constructor.name
So there are circumstances in which constructor.name doesn't work. But there are also circumstances where instanceof doesn't work, though i can't remember now which they were. It'd be nice if there is one that always works!
Peter Kahrel wrote:
>
> So there are circumstances in which constructor.name doesn't work. But there are also circumstances where instanceof doesn't work, though i can't remember now which they were.
instanceof does not recognize inheritance hierarchies. Superclass/subclass
relationships are difficult to work with in JS because that's not how the
underlying JS type system really works. There are some JS libs out there that
add this kind of capability, but it is via add-on methods and properties and not
seamless at all. Coming from programming in Java, it took me at least a year to
really grok how JS really works to the point where I could comfortably do any
kind of meaningful OO work.
> It'd be nice if there is one that always works!
Ultimately it depends on the context. You have just have to _know_ be it by
testing or by documentation. I use a relatively consistent coding style so that
I've reduced the possibility of this blindsiding me.
The next rev of JS is supposed to address some of these issues.
42
Replies
AdChoices