[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 #34 from Kyle Simpson <getify at gmail.com>  2013-04-14 14:15:09 PST ---
(In reply to comment #30)
>> What use case would it serve to leave them re-bindable...?
> 
> The burden of showing use cases is on people arguing to do something unusual, not on the ones saying we shouldn't, just as you don't get to say "what are the use cases for *not* implementing my feature proposal?".

Fortunately, several use cases have already been presented in this thread, so I don't really feel the burden to repeat them. That you don't like or agree with them is not sufficient grounds to imply that none have been presented.

I was merely pointing out that some use-cases do exist where this hard-binding would be nice (as listed), and asking if there are any contrary use-cases that I was missing. Sounds like there are none, or you don't care to spend the time to illustrate any.


> ("Shorter typing" to save 14 characters in uncommon scenarios isn't something that I can take seriously

It's a little deeper than "shorter typing" because what we're actually suggesting is that there cases where people are using `console.log()` without understanding the caveats that `console` is not just a namespace for the generic `log()` name, but a critical contextual component to identifying which place the log output should be directed.

I get that, and I wish everyone did, but I think many (maybe even most) don't understand that subtlety, so the loss of context breaking `log()` is confusing and surprising.

I myself even worked at Firefox for 9 months, on the developer tools team, and it hadn't occurred to me until reading this thread that there could quite possibly be multiple targets for console output. You can't seriously think that this is a detail that all JS developers just readily and automatically understand.

That's *especially* true if you don't do any `this` style programming at all in JS, where you prefer for instance module patterns and closures, and you almost never deal with loss of `this` context. You can be quite an experienced and prolific JS coder and never run into those issues, and then you merrily come along and try to deal with `console.log()` for some debugging, and you may get surprised.

Point being, it's not just about the characters, and I think you're being a bit too glib in suggesting that is the main point of this thread.

-------
That having been said, I cannot deny that saving the characters in this specific sort of usage (which I do *all the time*) would also be really nice:

`Object.keys(myobj).forEach(console.log)`

as opposed to:

`Object.keys(myobj).forEach(console.log.bind(console))`


> I don't know what you mean by "nicer abstractability".)

I thought there was already some implication of "logging abstractions" earlier in the thread, but I'll give one example to put slightly more concrete on it.

Imagine I have a multi-purpose logger utility in JS... in some circumstances, such as production, I don't want logs going to the JS console, but instead want to capture and transmit them to the server. In other cases, like dev, I do want them to go to the console (and maybe also get logged offsite).

Now, imagine, this API passes around a `log` function through my various contexts, that all my devs use to write out. It would be nicer, in terms of abstraction (and even narrowly, for performance), if I could pass around an actual reference to the console.log() function, for dev purposes, and only do a wrapped form of it when I need to hijack in production. But importantly, it'd be nice if the devs writing these `log(..)` statements didn't know those details, and didn't have to care whether the real or fake `log()` was in play.

We can go down the rabbit hole further if you still don't think there's any cases where log abstractions exist or are useful, but this is just one of many ways I could see a defaulted hard-binding being slightly nicer.


> > I understand the general argument of "so it works like all other methods", but in JS in general, there's lots of usefulness to be able to borrow functions and manually set their `this` object... except in the specific case of the console.* functions, I'm just not seeing that usefulness. Am I missing something we'd want to preserve?
> 
> Am I missing something that makes the console functions special and different from everything else?  It's just another API like any other, and a particularly simple and mundane one at that.

Yes, I guess you are missing what makes them special. I thought that was self-obvious so I didn't get specific at first.

In normal `this` style JS programming, if there's a function like:

```
var obj = {
   me: "obj",
   identify: function() { alert(this.me); }
};
```

There's a variety of ways that I can borrow that `obj.identify()` and use him against my own objects (overriding his `this`), so it's nice that, by default, `obj.identify()` has this re-bindability, through `call()` & `apply()`, as well as `new`. Of course, you could come along and hard-bind the reference with `obj.identify = obj.identify.bind(obj)`, but by default, his unbound nature can be quite useful and flexible.

However, by contrast, the core implementation of the `log()` function, as far as I'm aware, could not possibly be borrowed and reused against any random JS object in any useful way, as certainly rebinding `log()`'s `this` to something other than the legitimate `console` object in a specific window context would NOT result in any successful logging. At best it would silently fail, but it seems pretty likely it would error in an ugly way.

Point being, in normal JS, methods of objects default to being non-hard-bound so that they can more flexibly be reused and borrowed and such, but the console.* methods really have no value in being borrowed, because their very nature constricts them to use against a well defined window context.

Hence, my core argument that since these methods are not like all other JS methods, then having them, by default, hard-bound to the context they need to be bound to, **might** be justifiable.


> > Seems to me like the lesser evil would be to remove some surprises from the use cases stated here, at the almost zero cost/risk of surprising someone who's intentionally doing something very strange like trying to rebind `log()` to some other object.
> 
> This is a non-argument, since you could make it for pretty much every API on the platform.

No, not any API. Most APIs exposed to JS benefit from re-bindability. These console ones don't seem to have any re-bindability benefit, so I think they're at least potential candidates for special handling.

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