How do you let Ruby Salary objects compare amounts in == without making amount public, and why does private fail there?

## The problem A `Salary` value should not reveal its amount to arbitrary code, but two salaries still need to compare equal when their amounts match, and to sort. ```ruby class Salary def initialize(amount) = @amount = amount def ==(other) other.is_a?(Salary) && amount == other.amount end private def amount = @amount end Salary.new(5_000) == Salary.new(5_000) # NoMethodError: private method 'amount' called for an instance of Salary ``` The left side, `amount`, is fine: it has no explicit receiver. The right side, `other.amount`, is rejected. Ruby's `private` is **per object**: only the receiver-less form or the literal `self.` may call a private method, and the fact that `other` is also a `Salary` does not matter. ## The fix: protected Replace `private` with `protected` for the reader: ```ruby class Salary include Comparable def initialize(amount) = @amount = amount def <=>(other) other.is_a?(Salary) ? amount <=> other.amount : nil end protected def amount = @amount end ``` Now the rule that applies is protected's: 1. The call `other.amount` has an explicit receiver. 2. Ruby checks the object running the calling code, the `self` inside `<=>`. 3. That `self` is a kind of `Salary`, the class that defines `amount`, so the call is allowed. 4. Outside code, whose `self` is not a `Salary`, gets `NoMethodError: protected method 'amount' called for an instance of Salary`. Instances of a `Salary` subclass pass the same check, so a `Bonus < Salary` can compare with a plain `Salary`. ## Details that come up - **The type guard matters.** Without `other.is_a?(Salary)`, `salary == 5000` calls `5000.amount` and raises `NoMethodError`. Equality should answer `false`, and `<=>` should return `nil` for incomparable values. - **`respond_to?` ignores protected methods.** `salary.respond_to?(:amount)` returns `false`; `respond_to?(:amount, true)` includes private and protected methods and returns `true`. - **Performance.** The `Module#protected` documentation notes that protected methods are slower than others because they cannot use the inline cache. For a comparison called in a tight sort loop that can matter, and some teams compare an exposed, harmless value instead. - **Scope.** Protected methods are still visible to every object of the class family. If the value must not reach even peers, compare in a way that does not expose it at all, for example with a public method that returns only the comparison result. ## Alternatives to protected Protected is not the only design that keeps the amount out of public view: - **Expose a comparison, not the value.** A public `<=>` or `==` is itself the interface; callers learn the ordering without seeing the number. - **Expose a safe projection.** A public method returning a band or a rounded figure may be enough for callers, and peers can compare that. - **Compare a value object.** If the amount is wrapped in its own immutable object with public comparison, `Salary` can delegate to it and keep no protected methods at all. Each of these trades a little extra code for a clearer statement of what outside code may know. ## Choosing between the three | Need | Visibility | |---|---| | anyone may read the amount | `public` | | only the object itself uses it | `private` | | objects of the same family must read each other's value | `protected` | `protected` is rarely needed outside comparison, arithmetic between value objects and merging objects of one type; when it appears elsewhere, check whether a public method or a private one would say more clearly what is intended.