[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 #23 from Glenn Maynard <glenn at zewt.org>  2013-04-12 06:18:08 PST ---
(In reply to comment #22)
> Glenn, I'm obviously going to defer to you on this, but here are a couple more thoughts.

I'm just another web developer offering his input--the decision is up to WebKit folks.

> First, the main goal of console.log and its cousins is to speed up development. It's already very different from the other Web APIs, because it "talks" to another world (the debugging console), and it has "superpowers" (e.g., it can enumerate all the properties of an object when dumping it). I think that making console.log as useful as possible should trump consistency with DOM APIs, because it's not really a DOM API. (for example, it's in node.js as well). At the same time, I recognize I'm really biased, because I think that speeding up Web development would give us cool new toys to play with :)

If console.log was actually inconvenient, I might agree, but I don't think it is.

> Also, since you brought up the issue of a specification, I think console should have been Console, and Console.log should have behaved like IDBKeyRange.upperBound, which is a static method. I also think that being able to log to another window's console is a bit confusing, but at least that's self-inflicted pain. Last, having a Console singleton would justify exposing it to Web Workers. (it'd work in an obvious way for dedicated workers, shared workers are a bit more difficult) But that's water under the bridge now, since console.log is a de-facto standard.

Web Workers can still support console (and really, really needs to), but it'll take some thought to figure out which window's console logs should go to.  That's simple for dedicated workers, but shared workers are trickier.  (This is a more general problem, see http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0283.html, so maybe a general solution will be found.)

> Second, in my experience teaching Web development to MIT students, people learning JavaScript are thoroughly confused by "this" anyway, because of the way it's bound in DOM events. I conjecture that by the time they figure out "this", people would be able to handle the console inconsistency, and be grateful that the browser developers tried to make console.log more useful for async APIs. In summary, I think Firefox got this right.

I think this is a case of "everyone agrees consistency is good, and everyone thinks their case is the exception".  Adding inconsistencies to the platform is bad, since it's a big, complex system, and I don't see the justification for this one.

Where is console.log not useful for async APIs?

> Last, if you're really against special-casing console.{log, info, error, ...}, would you be willing to entertain the idea of supplying bound console functions, in a manner similar to "dir", in the Inspector?

I won't be too bothered by things WebKit does in web consoles, since it doesn't affect the Web--it's an implementation detail.

But, I still don't understand the use case.  I've never had to say "console.log.bind(console)" in a console.

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