minor request on logging classes

[jimmywarting]

When logging object, functions and classes you sometimes see function and classes being printed the same way as such:

I wish they where a bit more distinguish if it is a function or a class so you know if you have to call the "function" class with the new keyword and expect something back
kinda like chrome's devtool:

with the prefixed class and f in the beginning

maybe with an other color (same as the number color - orange) or like my atom editor:

it's not so much about styling, (the above are just some suggestions)
the request feature is just more about distinguish classes from functions in the terminal

(don't mind as much if this is being discarded and closed since it's not so important to me - just wishful)

[addaleax]

I think implementing this could call .toString() on the function and check whether that starts with class – that should be doable.

[BridgeAR]

@addaleax I already have a local implementation that does exactly that. It is a bit tricky handling the edge cases though. E.g. const a = { class () {} }. We have to make sure we only match correct entries.

[jimmywarting]

It's a start...

typeof v === 'function'
  && v.prototype // undefined if arrow fn
  && v.constructor?.name !== 'GeneratorFunction'
  && /^class\s/.test(Function.prototype.toString.call(v))

maybe should be some native builtin way to handle it.

on a side note i notice that chrome devtool also prints f* name(){} for generator functions - that * is also useful

[devsnek]

I'm -1 on testing for class because that fails on babel output and just people who still write classes using function. the fact of the matter is that some js functions need to be called with new (ones created with the class keyword, builtins, babel output, etc), and some don't, and there's no way to know which.

[BridgeAR]

@devsnek if I understand correct you worry about people relying upon the suggested class output in a way that it's always possible to invoke all functions without new?

I would not worry about that since it's no guarantee, just an indicator?

[devsnek]

based on the OP it seems like people would rely on this. my concern is that something this finicky it might just end up being noise.

[jimmywarting]

honestly I wouldn't rely on it that much. I just don't see classes as a function so i don't think they should be named as such to begin with.

classes are extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods).

i.e: not a function that you can call and expect something to happen or give you a result. it's something you instantiate.

it's like @BridgeAR said: it's no guarantee, just an indicator to help you distinguish things out from the mass. and helping you figure out what things are a little bit earlier.

--

@BridgeAR, do you mind sharing your local implementation that solves this?

[devsnek]

@jimmywarting regardless of where this issue goes, i'd suggest changing your mental model of classes because they're just sugar for
function YourClass() { if (new.target === undefined) { throw new TypeError() } }

[BridgeAR]

@jimmywarting I just opened a PR to implement this. It includes lots of edge cases in the tests in case you are interested in that. Chromium just prints the plain stringified value while this strips comments and adds further information.