Use destroy instead of delete

[lifeiscontent]

delete is a reserved word in JavaScript and since this guide helps people decide in generic situations, I’m suggesting to use destroy instead of delete, because in cases where using the word delete are not possible we should be promoting a solution that works everywhere.

[kettanaito]

Hi, @lifeiscontent. Thanks for the suggestion.

While delete is a reserved keyword, these guidelines recommend using the phrase "delete" as an action prefix, meaning it always has another word(s) following it. There is no language violation that way.

deleteUser()
deletePost()
deleteItem()

There is no connection with the delete keyword.

The semantic meaning of "delete" is a great counterweight for "create", so I don't think we should stop recommending it.

[kettanaito]

"Destroy", on the other hand, is more the opposite to "construct" then "create" (my subjective opinion). "Destroy a post" doesn't read naturally, to be frank.

[lifeiscontent]

@kettanaito so I totally agree with you there. However it conflicts when being applied with "Avoid context duplication" as new developers are learning they might not know "delete" is a reserved word. And when you find something like this out, you're probably a bit far down the rabbit hole already.

Anyway if you feel strongly about keeping it, that's fine I'd just urge you to at least put a warning so people are aware.

[kettanaito]

Hm. Perhaps I'm not seeing it from the same angle as you do. Could you elaborate more on why you think the reserved delete keyword is an issue?

I fail to see a problem here, as it's the same as newUser or whileActive where both new and while are reserved keywords. That doesn't make those variable names unsustainable or problematic.

[lifeiscontent]

it more or less has to do with working with objects.

for example, I couldn't define a function on a post called delete without it casuing issues.

function Post() {};
Post.prototype.delete = function delete() {}; // Syntax error

[lifeiscontent]

ping @kettanaito

[silesky]

for example, I couldn't define a function on a post called delete without it casuing issues.

function Post() {};

Post.prototype.delete = function delete() {}; // Syntax error

Using a reserved keyword in the global scope as a method on a class is not a code smell on any JS team I've ever worked with. If I see someone who defined a class method e.g. "Address.with" "Address.for", I'm not going to flag it because it's a reserved word if used in the global scope.

The case that you shows is pretty far off edge case IMO. It only applies for people who want to use the desugared class declaration syntax, which are rarer and rarer, and only if someone want to use a named function. They could just as easily rename the declared function to something arbitrary rather than delete, since the prototype method name is the thing that matters. I probably wouldn't use a named functions here in any case, since most modern debuggers are capable of working with anonymous function and inferring their assigned name.

The other edge case if it was being used unquoted in an ES3 environment; but there hasn't even been a standard lint rule covering that since eslint 0.8.0 or so.

[lifeiscontent]

@silesky I'm trying to be mindful of newer developers on a team, I'm not saying my suggestion is right, but more or less having a conversation about a topic that might have some tension around it. I understand how to solve this issue myself, but newer developers might run into it as something confusing.

I am curious what the maintainers of this project think about this kind of thing and what the recommendation would be for guiding new devs into a positive path, as unlike yourself, new devs don't have your knowledge of the language, and its important to be mindful of all developers alike that is how you build a solid community for everyone.

I plan on recommending this guide to my team and they all have various experiences with the language so I'd like it to be as welcoming as possible because I care about them and how they understand things vs the facts of how the language works.