4 ms·
First, of course the principle of least surprise is good, but it doesn't apply here. No experienced Ruby programmer would look at 'a[0]' and think - oh, an inde
by mdemare 19y ago
First, of course the principle of least surprise is good, but it doesn't apply here. No experienced Ruby programmer would look at 'a[0]' and think - oh, an index into an array. They know that it could mean many things, depending on the receiver, not the subscript value.
Also in Ruby there is no overloading. Overloading means that a different method is chosen depending on the types of the arguments. That means that in C++, it is not true that "the type of an object and the method name invoked determine unambiguously the method that is called".
In practise there is also little overriding - there seems to be no need. In C++ there is a lot more, and because of multiple inheritance, things can get confusing. (Overriding and overloading are two ways in which OO-languages violate the principle of least surprise).
This means that the reasons why using operator overloading is bad in C++ don't (automatically) apply to Ruby.
- timr 19y agoI'm going to ignore your more pedantic points (e.g. method "signature" vs. method "name", and the silly notion of "overloading" in a dynamically typed language), and focus right on the meat of the argument: Every "experienced Ruby programmer" may well come to understand that standard expressions fail to mean standard things when used in Ruby; that doesn't make it a good idiom. The problem here isn't that the bracket operator fails to reference into an array -- it's that the bracket operator might behave inconsistently for certain subscript values. The STL map class is a perfect analogue: rather than implement an operator[] than could fail in certain contexts, the C++ standard demands that map::operator[] must always return an object. This is consistent behavior. Allowing operator[] to fail for subscript N-1 when it works for N? That's inconsistent (and confusing), but apparently, it's the Ruby Way.