[Webkit-unassigned] [Bug 19932] console functions shouldn't print undefined in the console

[bugzilla-daemon at webkit.org]

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





------- Comment #11 from aroben at apple.com  2008-07-08 12:12 PDT -------
(In reply to comment #10)
> (In reply to comment #9)
> > I think it's awfully confusing to have nothing print in a case like this:
> > 
> > >>> window.undefinedVariable
> > 
> > I think the only case where it's arguably better to have nothing print instead
> > of "undefined" is this case:
> > 
> > >>> functionThatIKnowReturnsUndefined()
> > 
> 
> I agree. Maybe we should detect function calls vs printing a property?

Perhaps. I guess getters would fall under the "property" case?

> > I don't think that case is particularly common, except for the console logging
> > functions. Even in this case there's an argument to be made for printing
> > "undefined", since it's consistent with all other cases.
> 
> Maybe other functions return undefined, any function that doesn't have an
> explicit return returns undefined.

That's true, returning undefined is pretty common in JS. I'm trying to
distinguish between functions where you *know* they will only ever return
undefined, and ones where you don't. For the former, printing "undefined" is
redundant. For the latter, it isn't. So I just worry that we'd be making things
more confusing overall. But maybe I'm not giving our developers enough credit.
:-)

> The main reason I don't like splitting them is the fact we don't visually
> distinguish the function result from any other console.log output. If we made
> it visually distinct it would be fine.

I agree, we should have a way of grouping the input with the output. I guess we
should talk more in bug 19931 about that.


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