From: radovan.smitala@... Date: 2017-09-21T07:25:42+00:00 Subject: [ruby-core:82914] [Ruby trunk Feature#12637] Unified and consistent method naming for safe and dangerous methods Issue #12637 has been updated by r.smitala (Radovan Smitala). duerst (Martin D��rst) wrote: > r.smitala (Radovan Smitala) wrote: > > > I also think migration to new method naming is really easy with simple regex replacing. > > It's not so easy. There may be programs with variable names such as `fill`, user written classes with methods that have the same names as the ones you want to change, and so on. You are right about migration. I don't count all variations of method using. > > And the more heavy cost is to change all the knowledge that all the current Ruby programmers already have. I think is is why Ruby popularity stagnatess or slightly decreases. No new blood or just little comes to community. Community get older. Many went to another language like Elixir not because they are fancy and new but i think because they are easier to learn and remember how they works. No different behaviour in whole language. Eg immutable, we no need to care about function behaviour. Everytimes it return new instance. And this is great. Uniformity. Things like pattern matching or pipe operator are just syntactic sugar. It could be added anytime. But adapt language to new needs is required to make this language live in future. Ruby is great language, i using it in my professional career for 8 years. Ruby's power it is human friendly universal language. Anyone can use it in imperative or functional way. And this is great opportunity to be bigger and more future-proof. But i think Ruby suffer for it's legacy. It was created in different age with different needs. Ruby is preparing for great version 3. Isn't this option how to change some things? For example global string freezing. How about this code? ```"hello".concat("world")``` will this code works with global string freezing anyway or it return exception? If it return exemption or return new string instance it is change on fundamental behaviour, because in documentation this method change receiver. In both ways old code will not work. I really like to see safe methods and dangerous methods cross all language. If i use ```"hello".concat("world")``` or ```"hello" << "world"``` i will know it returns new instance. But if i use alternative with examation mark/bang i know it changes it receiver (eg unfreeze string and write into same variable name). Isn't it easier to remember or to read by another developer? Ruby influence many languages like Elixir or Crystal. They use similar syntax because it is strong advantage of Ruby, but they remove all ambiguity and it is their strong advantage, but not for Ruby at this age. But as i use different languages more and more i miss some principles or functions in Ruby. Like spread operator for hash {...anotherObject}, better asynchronous syntax (async await), uniform behaviour cross all language (always new value), pipe operator etc. ---------------------------------------- Feature #12637: Unified and consistent method naming for safe and dangerous methods https://bugs.ruby-lang.org/issues/12637#change-66813 * Author: r.smitala (Radovan Smitala) * Status: Rejected * Priority: Normal * Assignee: ruby-core * Target version: ---------------------------------------- Hello, As a multi-paradign language allows programmers to code from imperative to functional style. This gives Ruby to be modern and wide used language in these days. Ruby is built on idea to be as fun, understandable and focused for people. But i think it carry "complicated behaviour" in some method naming. In this documentation is written: (http://docs.ruby-lang.org/en/trunk/syntax/methods_rdoc.html) > The bang methods (! at the end of method name) are called and executed just like any other method. However, by convention, a method with an exclamation point or bang is considered dangerous. In ruby core library the dangerous method implies that when a **method ends with a bang (!), it indicates that unlike its non-bang equivalent, permanently modifies its receiver**. **Almost always**, ruby core library will have a non-bang counterpart (method name which does NOT end with !) of every bang method (method name which does end with !) that does not modify the receiver. This convention is typically true for ruby core library but may or may not hold true for other ruby libraries. Hightlited part of citation talks about that method with exclamation mark modifies its receiver. What is good because i could choose between imperative habit and modify receiver, but i can also create new data and code in functional habit. Eg: i can create new array with **map** method, but always i can modify existed object with **map!**. What is incredible and easy to understand. Or i want to get unique values from array by **uniq** assign into new variable. Still it is able to modify origin array with **uniq!** Second highlighted part is about confused part. It tells to programmer be careful. Not all methods follows this great design. In Ruby are methods which are "inconsistent" in naming. Eg. Many built-in Array methods like * clear * concat * delete * delete_at * delete_if * fill * insert * keep_if * pop * push * replace * shift * unshift are dangerous because modify its receiver. What is confusing for many programmers and it brings unexceptional behaviour without study documentation deeper. I think Ruby is popular for people because it communicate with programmer like in human language. Nowadays are getting functional programming languages high popularity and trend increase more and more. It could be great to remove that one word ("Almost") and have Ruby as language more clear, unambiguous and brings more functional principles into language what we like and love. -- https://bugs.ruby-lang.org/ Unsubscribe: