domenic at domenicdenicola.com (2014-02-10T22:37:35.650Z)
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](http://bonsaiden.github.io/JavaScript-Garden/#types.instanceof) 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.
Andrea, 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 <http://bonsaiden.github.io/JavaScript-Garden/#types.instanceof>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. - Tim On Sat, Feb 8, 2014 at 12:00 AM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote: > 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 > > > > > > On Fri, Feb 7, 2014 at 8:27 PM, Timothy Quinn <tim.c.quinn at gmail.com>wrote: > >> Sweet. Thanks for the quick responses =D >> >> >> On Fri, Feb 7, 2014 at 11:24 PM, Erik Arvidsson <erik.arvidsson at gmail.com >> > wrote: >> >>> Function name is in the latest ES6 draft. >>> >>> On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn <tim.c.quinn at gmail.com> >>> wrote: >>> >>>> 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<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name>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. >>>> >>>> - Tim >>>> >>>> >>>> On Fri, Feb 7, 2014 at 10:52 PM, Timothy Quinn <tim.c.quinn at gmail.com>wrote: >>>> >>>> LOL. I did not realize that was implemented already :) >>>> >>>> Thanks, >>>> - Tim >>>> >>>> >>>> On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola < >>>> domenic at domenicdenicola.com> wrote: >>>> >>>> o.constructor.name seems good? >>>> ------------------------------ >>>> From: Timothy Quinn <tim.c.quinn at gmail.com> >>>> Sent: 2/7/2014 22:26 >>>> To: es-discuss at mozilla.org >>>> Subject: Efficient determination of implemented class name >>>> >>>> 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)") >>>> }; >>>> >>>> Thanks! >>>> Tim >>>> >>>> >>>> >>>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140208/339a3fcb/attachment.html>