-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Combine deno.removeAll into deno.remove #1596
Conversation
js/remove.ts
Outdated
*/ | ||
export async function removeAll(path: string): Promise<void> { | ||
await dispatch.sendAsync(...req(path, true)); | ||
export async function remove(path: string, recursive = false): Promise<void> { |
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.
Should we pass an options object { recursive: boolean }
instead of recursive = false
?
This makes it easier to extend the interface
At the same time, single boolean
will make people confused
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.
@axetroy Got it.
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 should declare an options interface
and exports it.
instead of a single boolean
argument
eg.
interface removeOption {
recursive?: boolean;
}
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.
LGTM
README.md
Outdated
|
||
``` | ||
curl -L https://deno.land/x/install/install.py | python | ||
curl -L https://deno.land/x/install/install.sh | bash |
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.
This is an unrelated change. Please remove
export function removeSync(path: string): void { | ||
dispatch.sendSync(...req(path, false)); | ||
export interface RemoveOption { | ||
recursive?: boolean; | ||
} |
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'm not a huge fan of these Options interfaces with just a single member...
But I think it makes sense to mirror the interface in deno.mkdir(d, { recursive: true })
cc @piscisaureus here is another example of a function which will never have more than one option.
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.
Nope! An option could be whether to remove readonly files also (not a thing on linux, but kinda important on windows and a thing on os x also)
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.
A good argument in favor of using options objects, even when they have a single member, is simply how confusing boolean traps are.
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.
FYI we recently added this to the style guide https://github.com/denoland/deno_std/blob/bef7ba14303997a05cdd1ea0d28ffefeee75c993/README.md#exported-functions-max-2-args-put-the-rest-into-an-options-object
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.
LGTM
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.
LGTM
I rebased and squashed it - thanks @loujiayu !
It would be better to call it Should we unify the use of an option object for the other functions? For example On the other hand, it should be changed to And finally, should a new issue be opened for this? (Sorry for my English) |
Closes #1584