[icebraining]

I disagree, operator overloading often makes the code much more readable. I don't see the problem unless you're trying to write C in Ruby. As long as the overloaded implementation keeps the expected semantics as described in the language documentation, it's fine.

[TeMPOraL]

Most problems people have with operator overloading seem to be caused by the same issue that makes them whine about "debugging metaprogramming" (I referenced that in other comment here). Namely, instead of trying to understand the code and the model behind it, they try to bring over their own assumptions about how the code should work.

That 5-component object compared by ==? How does it work? Sit down, read the code and find out. The answer depends on what exactly the object represents and what makes sense in the domain model.

[JoeAltmaier]

That's exactly the issue. When its a small program that works fine. A large one? Its a matter of time and effort. Anything can be looked into, with time. Which is money. And effort over time ~mistakes.

Its too simple to do victim-blaming here. You don't understand my code? Well, just read it all so you know how clever I was.

If you want to write code that can be easily assimilated, which most readers would think they understood from its source and not by reading it at some meta-level, then you have to code with one hand behind your back.

[JoeAltmaier]

Its not ever 'fine'. Its confusing at best. Imagine a component with 5 attributes. Does '==' match them all? Some of them? Loosely or tightly? I'm afraid just seeing '==' in the code is never going to be informative.

Instead, maybe a method MatchAttr1And2(v1, v2) would certainly tell a subsequent reader a little more about what's going on.

[msbarnett]

> Imagine a component with 5 attributes. Does '==' match them all? Some of them? Loosely or tightly? I'm afraid just seeing '==' in the code is never going to be informative.

This is, fundamentally, a disagreement about the value of encapsulation. With an opaque, encapsulated type, '==' should mean whatever makes the most sense in the context of that type. For a pointer that might be "equality" means "same memory address", whereas for a vector that might mean "equal components". As a user, "equality" should match an intuitive understanding of what it means for two things of this type to "be the same". It's an art form. Like many things in programming, doing it well requires good taste.

Operator overloading is a powerful technique for preserving encapsulation. It's the polar opposite of:

> Instead, maybe a method MatchAttr1And2(v1, v2) would certainly tell a subsequent reader a little more about what's going on.

This leaks implementation details like a sieve. It's a great recipe for encouraging dependency on a particular implementation detail across module boundaries, and rolling yourself a great heaping ball of mud.

[JoeAltmaier]

Only if you do it that way. Make it MatchForParticularPurpose(v1, v2) instead, and voila no leak.

Operators are unique in the language. They hold a special place. They deliberately are written to imply something we already understand. No fair lumping them in with every other attribute or method of an encapsulated type.

Intuition is a very, very poor thing to depend upon in a programming language. I disagree heartily that it should be the solution to disambiguating any operation.

[msbarnett]

> Only if you do it that way. Make it MatchForParticularPurpose(v1, v2) instead, and voila no leak.

Making the name more opaque won't save you at all. You're making what should be a local detail -- how your type implements equality -- into something that only works when it is global knowledge.

Consequently, your type is brittle and incomposable with types that aren't infected with this knowledge:

    [instance11, instance2, instance3].sort

won't do anything sensible until we infect either the Array type or the call site with non-local knowledge about your type.

Every type you build in this manner will find knowledge about itself diffusing throughout your application, like children peeing in a pool. Composition will be limited, inflexible, and require manual insertion of type-specific knowledge, because you have failed to encapsulate knowledge about equality.

Everything needs to know about everything else, and in the end you've built a tightly coupled ball of mud.

[cdcarter]

> Operators are unique in the language. They hold a special place. They deliberately are written to imply something we already understand. No fair lumping them in with every other attribute or method of an encapsulated type.

I would argue that a CORE value of Ruby is that everything is an object, and objects communication by message passing. Treating an operator as anything other than a message between objects is fundamentally wrong.

If you expect operators to do anything other than call the appropriate message on an object, you're misunderstanding the syntax.

[msbarnett]

Indeed, in a very real sense Ruby simply doesn't have "syntactic operators" in the C-ish sense he seems to regard them.

Ruby only has messages. Some of those messages just happen to have punctuation for names.

[regularfry]

If the code you're dealing with makes you care what the equality operator is doing internally, it's not well enough abstracted.

[icebraining]

Sure, for some cases, == is not immediately clear. Don't use it in those cases.