console.count and console.timeEnd should return the value of the count/timestamp

[jsnajdr]

The console.count, console.timeEnd and console.assert methods do two things:

1. compute some value (named timer/counter value, assertion result)
2. print the value to console

In many debugging scenarios, it would be very useful to get the computed value as a return value from the console.* call. Enables things like logging difference between two timers or counts etc.

The console.assert return value proposal is already reported as issue #63.

[domfarolino]

count

I'm a big fan of this for console.count, as the values could be useful saved off to the side and used later (plus this can make web-platform-tests more explicit).

assert

The return value of console.assert could be useful in conditionals (plus you get the side effect of fancy logging on failed assertions), however we might want to make sure this issue resolves with Nodejs making their assert more passive and not throw on failed assertions instead of spreading the implementation gap even further.

time

I have no issue making this return something, as some people may find it useful to save a time value for future human-readable reference but it is worth mentioning that this PR https://github.com/whatwg/console/pull/105 makes the format of the time non-standard.

@JosephPecoraro @paulirish @xirzec thoughts on this? Shouldn't break anything and I assume can just be more helpful.

[xirzec]

@domfarolino Sorry for the slow reply. This seems like a reasonable enough proposal, though I have to glance at our implementation to confirm it would be easy to add. Some questions though:

1. What should happen when the tools are closed? For performance reasons we no-op a lot of console commands when the devtools aren't open or replace them with simpler native versions.
2. What about other console methods? E.g. log doesn't return the formatted string.

[domfarolino]

@xirzec No problem, I've ben a bit bogged down with school etc.

1. In general (not specific to these methods) the spec indicates in the last sentence of the Printer that output should be buffered and displayed at a later point when the devtools are opened. Off the top of my head I'm not sure how well this is followed though.

2. Personally, I think the argument to support console methods that return values would be to have access to some internally maintained data that the user of the method doesn't easily have elsewhere. For example when I log a variable, the only thing the implementation has to do is log it, it doesn't provide me with any values I don't already have (i.e. the value of the data passed in), as I was the one who passed it in in the first place. With count and time specifically, they have access to some internally maintained data (for example a timer running in the background) whose value (represented by a label) the user doesn't have access to without calling the method (or re-implementing it themselves). Since implementations end up Printing this data (a computed counter or timer) it could be equally useful to be able to store it elsewhere.

Hopefully my analysis makes sense :)

..although maybe it would be useful for log to return a formatted string..off the bat I say probably not though.

[xirzec]

I see what you mean now. Yes, it makes sense to me to have the methods that hide state expose it in some easy-to-test fashion.

[fmartin5]

I think this would be too much responsability for these methods. Printing to the visual output device and returning a value for other computations are two distinct jobs. Also, mixing direct effects and side-effects in the same method doesn't look a good design to me.

1. Wouldn't we lose the current ability to easily remove any console method call from user code without interfering with any program state or logic? Now, users and tools that naïvely remove console.* calls from code might break it.

2. What about feature detection? Other console methods are easy to detect with a simple idiom, but how would I check whether the available implementation returns a value, without actually calling it (to avoid side-effects)?

So if a way to access internal console data is deemed useful enough, I would rather have some distinct, side-effect-free, get-prefixed methods like e.g. console.getCount().

[domfarolino]

These are good points. Regarding the first one, it would be a big issue if application code could start depending on the output of console methods, especially while tools strip console calls out. I'm not sure how common a trend this is though. The point of this spec is to define "APIs for console debugging facilities". I guess while there might be some benefits to having access to something like an internal timer, if we provide that, there's no bulletproof way to tell developers:

"Make sure you're only using this in a debugging situation where your app doesn't depend on it, like logging back to a server etc."

Also, having count() return a value, as you mentioned, would definitely have side effects. We'd need the getter you mentioned, but then that circles back to the first problem of developers maybe depending on it. I'm a little less in favor of making some of these methods actually return values now. What makes it worse is that some implementations (it sounds like Edge, from @xirzec 's comment, and I believe Safari) no-op console methods when the developer tools are closed. Whether the developer tools are open or not should not have an observable effect, and this problem would be worsened if some methods are no-oped, and no-opping implementations don't find a compelling-enough reason to change.