> Your example could be fixed in your entire codebase with a single sed invocation

I also have to hope all the dependencies I use did that, too.

But my real question is why? Why make me do it at all?

Because they wanted to, and it's their project. Part of being an adult is accepting you won't agree with every decision that affects you.

You were free to show up and argue against it, as was anyone else. Did you?

▲

cortesoft 2 days ago | parent [-]

Ok, I think you are arguing against something I am not saying.

I am not arguing that they don’t have the RIGHT to make the change, or that they owe me personally anything. I am not even THAT mad. I still love Ruby the most of any language, and generally think they make the right decisions.

I am simply annoyed by this decision.

And yes, I argued against this change when it was first proposed (as did many others). They obviously were not convinced.

Again, I am not arguing that they should be FORCED to do what I want, or that they did something shady or nefarious by making this change. I am not asking for any remedy.

I am simply saying I disagree with this type of change (changing a method name because some people feel the new name makes more grammatical sense, but not changing the method itself at all). The reason I commented was because this is not a “we have to deprecate things for progress” situation. They aren’t limited in any way by the current method, the syntax isn’t cumbersome (and isn’t changing), there is no other capability that is held back by having to maintain this method. It is literally just “I read it as asking ‘Does this file exist?’ rather than asking ‘This file exists?’”

Again, they are obviously free to disagree with me, which they do. I am simply arguing that we shouldn’t break syntax just because you like the way it reads better without an s. And I am asking for someone who disagrees with me (you) to explain why it is worth making this type of change.

	▲	jcalvinowens a day ago \| parent [-]
		It's important for code to be clean and free of old cruft, even if that means old code has to change. Readibility is one of the most important aspects of maintainable code. Arguably more important than testing, IMHO. This is another reason open source solutions so consistently win over corporate ones, the open source world understands this. Are there changes I disagree with? Of course. But I'd rather live in a world that moves forward and occasionally breaks me, than one where I have perfect compatibility but am stuck on code lacking the new innovations my competitors benefit from. The whole idea behind deprecating things is to give people time to make the changes before they become breaking. I went and looked: exists? was marked as deprecated in 2013 and removed in 2022. That's enormously generous, my previous comparison with the disttools debacle in python was inaccurate. You had a decade!