This repository was archived by the owner on Apr 21, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 34
Adds callback parameter to the log and other functions.
#73
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
835c136
add a callback to logging functionality
lvilya 023b188
lints
lvilya 59255b4
address some comments
lvilya 523553e
nested describe block.
lvilya 760d93c
lints
lvilya 669b426
spelling
lvilya 0e6327b
bhvsdf
lvilya 13e64d9
space between the brackets
lvilya File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We seem to do this a lot and it seems to me like a terrible idea - it's confusing to me that we can let people send in a callback function as the
optsparam. Wouldn't it be preferable to require them to send in an empty/nulloptsand be explicit about whatcallbackis than this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't answer my question, but I really dislike this - let's keep each parameter as it's meant to be instead of pseudo-overloading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry I did not see your comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dchai76 I think it's arguable. On one hand the implementation of the code library becomes harder to read and maintain. On the other hand, usage of our code libraries becomes easier (you don't have to write your code likes this
logger.log("my lolg", {}, (err) => {if err stdout)});every time when you need to pass the cb to the log function. I think it's better to take the burden of readability on us than pass it on users.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and besides, we can also pass a level to that. And it can grow into
log("logline", "", {}, cb). Which I think is not a really good practice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, I think this is bad for callers, not for our own maintainability - magic overloading can mask errors on their part. Did they mean to forget to include opts? Or was it intentional? The type of magic where we say one parameter can be treated in different ways is surprising, and not in a good way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't like this pattern, but I do see this used in lots of places :(
I guess the best way to escape is the make it an async function that returns a promise, so up to the caller whether to chain it or not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weizou19 pointed out to me that Node itself does this (magic overloading of provided callbacks) (https://github.com/nodejs/node/blob/master/lib/fs.js#L405-L414) so as much as I dislike it I'm going to say I'm wrong on this.