[Webkit-unassigned] [Bug 20141] Cannot call pointer to function console.log

Thu Apr 11 20:15:04 PDT 2013

https://bugs.webkit.org/show_bug.cgi?id=20141

--- Comment #20 from Victor Costan <costan at gmail.com>  2013-04-11 20:13:17 PST ---
Glenn, thank you vey much for your feedback! I hope you will reconsider your opinion, based on the following arguments.

(1) I think there is great value in having developers be able to use "console.log" in a bound form while debugging any Web page / application. Changing the source code of the page I'm debugging might be a hassle. Also, if I'm debugging a library using its unit tests page, I wouldn't want to mess with the browser environment. bind works, but having to use it breaks the "I'll just type this one-liner in the Web Inspector" flow.

(1') All the developers that I talked to were happy to hear about this possible change. I think this is worth a bit of extra complexity in the code. Being able to pass console.{log, warn, error....} as an async is a nice little useful debugging tool, and having to do some setup from it detracts from this.

(2) "console" is a singleton, so we don't really need "this" to decide what to do. To a Web developer, the TypeError seems like being fussy for no reason.  To the best of my knowledge, getElementById works for any Document and DocumentFragment instance, so calling it without a value for "this" would be ambiguous.

(3) The WebIDL warning mentions specifications, and WebKit is an implementation.

(4) The WebIDL warning also mentions "unless for compatibility reasons". Using console.log unbound works in Firefox, so one could argue that this helps compatibility. The complaints in this Chromium bug, though unverified, seem to indicate that some developers assume console.log will work.

http://crbug.com/167911

Sorry for the long response, and thank you very much for reading it!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.