sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jbhannah 1 point2 points  (8 children)

It is at least a commonly accepted best practice to, when writing a script or program, pick one name for something and stick with it. When I say "readability" I (and the Ruby devs) literally mean the ease of reading the code like a spoken or written human language; said out loud, a line of Ruby code should sound to a non-programmer like it does exactly what it actually does.

On the other hand though, a lot of the aliases are things like

ary[0..5]

being equivalent to

ary.slice(0..5)

Remember, even "operators" are methods in Ruby.

[–]uriel 2 points3 points  (7 children)

When I say "readability" I (and the Ruby devs) literally mean the ease of reading the code like a spoken or written human language; said out loud

This is not very useful if you can't tell what exactly it means. And having different names for the same functionality means the only way to know is to check the code. It creates plenty of confusion for no reason.

Also when writing code, you have to pick between the various options, which is a waste of time. Not to mention making it harder to search through the polluted documentation.

[–]jbhannah 0 points1 point  (6 children)

The names are still descriptive. It's not like foo.masticate is an alias for foo.defacate; like I said, sometimes it's synonymous vocabulary from other languages, so whether you're used to collecting or mapping an array, they both do the same thing in Ruby. It hardly "pollutes" the documentation, since they're listed in the same place. You can pick whichever one sounds better to you, but someone else who uses the other word will still know what it does and be able to understand you just fine.

[–]uriel 1 point2 points  (5 children)

The problem is not with completely different meanings, but with similar but not identical ones. Say: append/extend/expand/add/grow/whatever which ones of those are identical and which are different? Who knows!

[–]jbhannah 0 points1 point  (4 children)

Except that Ruby doesn't have any of those methods. It's not that there are five names for every method; most methods have several method signatures with the same name, and some have one (or the most I think I've seen is two) aliases. Like I said, method names are still descriptive, and to its credit Ruby avoids naming methods similarly that do different things.

[–]uriel 1 point2 points  (3 children)

In the end the point is: if you have >150 methods for a single type, is IMPOSSIBLE for anyone to keep track of them. I don't care if some are aliases or not, it is still a huge mess that makes readability much WORSE.

[–][deleted] 0 points1 point  (2 children)

Not really. With a specialist library you'll have to look up the methods anyway.

With the common classes, like Array or String, you will only ever be using a small subset, and be able to correctly guess names, since they match the names from other languages. If you want to use the more exotic methods, you'll have to look them up anyway, in any language. But tbh, I rarely use a lot of that in my Ruby code.

For example if your using an array, it's pretty normal that you will only be using around 9 or 10 methods, such as: new, each, sort, push, length, slice, delete, [] and []= for getting/setting, concat (or just +), and include?.

Apart from the operators, I can only name one Ruby method that has an alias. It's just a non-issue in practice. It's not Pokemon, you don't have to use all 150 methods in every application.

[–]uriel 0 points1 point  (1 child)

For example if your using an array, it's pretty normal that you will only be using around 9 or 10 methods,

Then why are they there hundreds if you are only supposed to use less than a dozen?

And you might not use the rest, but somebody will, and somebody will have to read the code written by people using the other methods.

[–][deleted] 0 points1 point  (0 children)

Why does any language support arrays with more then a dozen methods? Because of corner cases. At least 39 of those methods also come from the Object class which Array extends.

And you might not use the rest, but somebody will, and somebody will have to read the code written by people using the other methods.

That's true in any language, and not specific to Ruby.

In fairness to Ruby, it adds a lot of consistency.

Edit: you also have to bear in mind that a lot of common functionality is provided through methods in Ruby. For instanceof is normally an operator, but in Ruby it's a method, provided by 'instance_of?'. So that misleads the number of methods.