Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js console.dir #79

Closed
Fishrock123 opened this issue Dec 19, 2016 · 4 comments · Fixed by #107
Closed

Node.js console.dir #79

Fishrock123 opened this issue Dec 19, 2016 · 4 comments · Fixed by #107
Assignees

Comments

@Fishrock123
Copy link

Fishrock123 commented Dec 19, 2016

Node.js has implemented a console.dir(obj[, options]) since Node v0.1.101.

From what I can tell, it appears to be a more direct sort of proxy to util.format() allowing the passing of options rather than additional objects.

@domenic
Copy link
Member

domenic commented Dec 19, 2016

dir is tracked in #27 FWIW. Someone should really fix that... slapping "good first bug" on it doesn't seem to be working :)

@domfarolino
Copy link
Member

This can be closed since dir has been added but I noticed browser implementations don't seem to support the optional options object that Node does. It also doesn't seem really applicable to browser implementations but I'm wondering if the API difference matters at all, or if we should at least make a note about it in the spec?

@domenic
Copy link
Member

domenic commented Mar 26, 2017

Hmm. This is a case where I think it doesn't hurt anyone to include special optional Node.js-only provisions. E.g. an optional argument for the options which anyone can use to customize the behavior of Printer, but in practice only Node.js uses this flexibility.

Based on the source code in Node plus the definition of Object.assign it looks like IDL of optional object? options would be equivalent. I believe such IDL cannot throw any exception, and I know it will not impact console.dir.length, so browsers that totally ignore the argument will be compliant.

Then we could modify step 2 to say something vague like "optionally using the properties of the options object to customize display". Or we could add a third arg to Printer, pass it through, and add a sentence about optionally using the third arg (if it is not undefined or null) to customize the display; that might be cleaner.

The only possible downside of this is that it constrains browsers from ever using the second argument in some different way. But that doesn't seem like a realistic fear.

@domfarolino
Copy link
Member

Yes I favor the third arg over the method doing stuff that is in Printer's domain. The optional + nullable options object sounds good thanks for digging in. Going to reopen this until I take care of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants