Discuss
  • Efficient determination of implemented class name

Efficient determination of implemented class name

# Timothy Quinn (12 years ago)

An area of challenge in JavaScript is the ability to detect a JavaScript objects implemented class name. I have done this in the past with some success by parsing the objects constructor but I know that this depends on the Object constructor being named and is not very efficient as it requires the processing of a large string.

Is it possible to include into the ECMA Specification a method of Object that returns the constructor function name which can be subsequently be used as an efficient class name detection mechanism? Maybe <Object>.getFunctionName().

My current current slow but steady method for detecting classes is as follows:

function objClassName(o){
    if(o===undefined){return "(undefined)" }
    if(o===null){return "(null)" }
    var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
    return (a && a[1] ? a[1] : "(unknown)")
};
# Domenic Denicola (12 years ago)

o.constructor.name seems good?

# Timothy Quinn (12 years ago)

LOL. I did not realize that was implemented already :)

# Timothy Quinn (12 years ago)

Digging into ECMA-262, I cannot find this noted but it appears to be implemented in V8 and SpiderMonkey.

Mozilla states this as non-standard so I am guessing that its not documented in ECMA-262.

Is this defined in the specification or did I miss it? If not, +1 on its standardization into the specification.

# Erik Arvidsson (12 years ago)

Function name is in the latest ES6 draft.

# Timothy Quinn (12 years ago)

Sweet. Thanks for the quick responses =D

# Andrea Giammarchi (12 years ago)

although, despite being advocated differently in every book/example out there, many developers do this:

Whatever.prototype = {
  method: function(){},
  property: 123
};

forgetting to redefine the constructor property that will also be enumerable at that time if re-addressed.

TL;DR obj.constructor.name is not reliable with non ES6 code, usually totally unreliable with old libraries producing always the string Object as result

Cheers

P.S. that check is pointless regardless, since your constructor.name might be inside a namespace you won't be able to address ... stick with constructors and instanceof you know, don't try to use constructor.name for any sort of magic in production ... just saying

# Timothy Quinn (12 years ago)

I agree about your note in the context of WAN based web applications. Unless one can constrain the browsers supported and the programming styles for JavaScript OOP, its would be un-dependable to use function.name

The challenge of instanceof is that its commonly recognized as fundamentally flawed and not useful. Thus the issue continues for a unified way of detecting the implemented class. JavaScript Garden's Object.prototype.toString method also does not work in all cases.

My original method of parsing <Object>.constructor.toString() has proven to be very stable in LAN based applications where the application stack and browsers are strictly constrained. My current library is for node.js so I should be able to trust the constructor.name for a majority of objects. I'm going to switch over to constructor.name for node.js and babysit the logic via strong assertions in the business logic. My initial unit tests have all passed with flying colors.

On a related note, one can only dream that formalized OOP class definitions can be put into the ECMAScript specification so we can move away from the lack of consistency for OOP. The flexibility is really hurting the language.

# Erik Arvidsson (12 years ago)

On Sat, Feb 8, 2014 at 3:56 AM, Timothy Quinn <tim.c.quinn at gmail.com> wrote:

On a related note, one can only dream that formalized OOP class definitions can be put into the ECMAScript specification so we can move away from the lack of consistency for OOP. The flexibility is really hurting the language.

Your wish has come true.

people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions

# Andrea Giammarchi (12 years ago)

of course if you know what you are doing and you own the whole code you can use whatever you think might work, mine was about interoperability with not always so good libraries code out there.

Function name is also historically misunderstood due IE declaration VS expression bug where latter is always preferred and you have tons of anonymous functions instead ... you know that ;-)