Opened 11 years ago

Closed 7 years ago

#9375 closed defect (wontfix)

support for WebKit's displayName feature of naming anonymous functions

Reported by: pmuellr Owned by: Rawld Gill
Priority: high Milestone: future
Component: BuildSystem Version: 1.3.0
Keywords: Cc:
Blocked By: Blocking:

Description

See:

http://www.alertdebugging.com/2009/04/29/building-a-better-javascript-profiler-with-webkit/

I suspect it would be possible to enable dojo to do some automatic naming of functions on behalf of the user. For instance, when defining classes, iterating through the properties looking for functions, associating the property name with the function name. Also on event handlers.

The logic should probably involve checking the "name" property of the function first, and if undefined, then setting displayName as appropriate.

The name doesn't have to be just the name of the function. I've played around a bit with some other frameworks where I tack on "class" names before the function name, and distinguish "class" methods from "instance" methods by separating the class and function name with different characters. eg, SomeClass?.classMethod and SomeClass::instanceMethod.

Change History (9)

comment:1 Changed 11 years ago by James Burke

We have something in the build tool that will add names:

symbol= Inserts function symbols as global references so that anonymous functions will show up in all debuggers (esp. IE which does not attempt to infer function names from the context of their definition). Valid values are "long" and "short". If "short" is used, then a symboltables.txt file will be generated in each module prefix's release directory which maps the short symbol names to more descriptive names.

Any suggestions on how to do this effectively at runtime without needing a build is appreciated. My first thought would be using some regexp goo before we eval the module (or in xdomain, before calling the function to define the module). Maybe we only do this kind of work if djConfig.isDebug is true or more likely if djConfig.debugAtAllCosts is true.

comment:2 Changed 11 years ago by alex

james:

for stuff that's declare()'d, I think we can probably go the distance by changing how declare() handles this stuff in debug mode. For other things (module-level stuff), I think we'll probably need toe extend the loader.

comment:3 Changed 10 years ago by alex

Owner: changed from anonymous to alex
Status: newassigned

comment:4 Changed 10 years ago by James Burke

Milestone: tbdfuture

comment:5 Changed 9 years ago by Chris Mitchell

Owner: changed from alex to dylan

please review/triage

comment:6 Changed 9 years ago by dylan

Owner: changed from dylan to none
Status: assignednew

comment:7 Changed 9 years ago by bill

Owner: none deleted

comment:8 Changed 8 years ago by bill

Component: GeneralBuildSystem
Owner: set to Rawld Gill

comment:9 Changed 7 years ago by Rawld Gill

Resolution: wontfix
Status: newclosed

With improvement in debuggers since this was filed, I'm not convinced this is still a real issue. For example, firebug gives you "anonymous" for unnamed functions, but also gives you the resource and line number...how much more help is a synthetically-named function?

Note: See TracTickets for help on using tickets.