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

[bugzilla-daemon at webkit.org]

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





--- Comment #21 from Glenn Maynard <glenn at zewt.org>  2013-04-11 20:44:17 PST ---
(In reply to comment #20)
> 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.

Sorry, I don't know what you're referring to.  You can just call console.log in web consoles, and anywhere you might say "x = console.log" you can say "x = console.log.bind(console)".

> (1') All the developers that I talked to were happy to hear about this possible change. 

I thought this was a good idea a couple years ago, too (comment #7).  I was mistaken.  Unless those people join the conversation and make technical arguments one way or the other, popularity contests aren't useful.

> 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.

Having to say ".bind(something)" if you want to take a reference to a function and use it as a standalone function is universal to the platform.  Having to do the same thing here that you have to do everywhere else enhances, not detracts from, the platform.

> (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.

No, console is definitely not a singleton.

https://zewt.org/~glenn/test-window-console.html

Here, we have two console objects, one for each window, and logs to each go to the corresponding window's console.

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

Do you think that APIs that lack a specification should do things which are considered bad practice for those that do?

> (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.

This change wasn't proposed for web-compatibility reasons.  I think you're hunting for arguments.

> The complaints in this Chromium bug, though unverified, seem to indicate that some developers assume console.log will work.

This incorrect assumption can be made for every single API on the platform.  You can just as easily try "create = document.createElement; create('div')", or any of the hundreds of other functions on objects.  Making it work for console isn't going to reduce confusion; it'll only make the platform more inconsistent, and make people even more confused when they find that this works with console, but pretty much nothing else.

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