It's an interesting trick, but for a setter method you really need to use `def cloaking=(value)` instead of overloading the same method. It would help to give a more realistic example for where this technique can be useful.
This expression returns true. It should be in a different scope from the default parameter value, so I assume it is equivalent to passing true directly.
def index_with(default = (no_default = true))
if block_given?
to_h { |elem| [elem, yield(elem)] } # rubocop:disable Rails/IndexWith
elsif no_default
to_enum(:index_with) { size if respond_to?(:size) }
else
to_h { |elem| [elem, default] } # rubocop:disable Rails/IndexWith
end
end
Who, other than the rather strange people in rails, write code like that?
It does not convey anything useful or meaningful. It is
complicated to read and not easy to understand. Just that # comment
there shows a lack of trust since it just appeases rubocop.
I have been critical of the rails people before, and this is another
example. They don't really write ruby code. Sure, it is valid ruby
code, but AI can write valid ruby code too and a monkey can as well
if given enough time (and tries).
My criticism is not confined to that alone, though. Take the
following:
NOT_PROVIDED = Object.new.freeze
Again, this is just madness. I am noticing that rails people
slap down .freeze onto everything. This. Is. Not. Ruby. You
don't see matz doing that. It is an anti-pattern.
I understand WHY it originated, of course; a lot of this has
to do with how strings were non-frozen in the past. Matz changed
this eventually, but that .freeze pattern still remains deeply
rooted in the brain of the rails people. They often come up
with craziness, such as ActiveSupport::HashWithIndifferentAccess.
Again, I understand why (don't want to care about Strings or Symbols
as keys); Jeremy wrote a rebuttal about this already, so I won't
repeat it (he is spot on), but I think it is time to end the rails
dominance in ruby in general. This is now, of course, much easier
with DHH going all-in on AI, and the most sad rails conference of
all times, where DHH declared how ruby on rails is de-facto dead
(now it is all AI rust, baby).
Ruby really has a ton of problems. I'll not repeat them here all,
but https://po-ru.com/2026/10/18/why-im-no-longer-updating-this-...
summarized it nicely. With Claude being the new de-facto language
designer, it may be best to completely re-think ruby. I do not see
ruby having a future as agentic AI slop surrogate. It will just
further accelerate decay against humans here, which is a problem other
projects also suffer. You can find that on many comments - it is a
real problem now. If you have two humans, and one claude slops all
the time, and even uses claude to "interact" with other humans, you
no longer communicate really. You kind of claude-cell isolated yourself.
I am not saying this is the case for all claude users, since some
understand the problem domain - but many others do not understand that
this is a real problem, which is shocking. Paul kind of understood
the emerging problem here.
Does it return back the empty current value?
I’m no ruby expert, but seems like the freeze approach avoids that with a unique inaccessible object.
It does not convey anything useful or meaningful. It is complicated to read and not easy to understand. Just that # comment there shows a lack of trust since it just appeases rubocop.
I have been critical of the rails people before, and this is another example. They don't really write ruby code. Sure, it is valid ruby code, but AI can write valid ruby code too and a monkey can as well if given enough time (and tries).
My criticism is not confined to that alone, though. Take the following:
Again, this is just madness. I am noticing that rails people slap down .freeze onto everything. This. Is. Not. Ruby. You don't see matz doing that. It is an anti-pattern.I understand WHY it originated, of course; a lot of this has to do with how strings were non-frozen in the past. Matz changed this eventually, but that .freeze pattern still remains deeply rooted in the brain of the rails people. They often come up with craziness, such as ActiveSupport::HashWithIndifferentAccess.
Again, I understand why (don't want to care about Strings or Symbols as keys); Jeremy wrote a rebuttal about this already, so I won't repeat it (he is spot on), but I think it is time to end the rails dominance in ruby in general. This is now, of course, much easier with DHH going all-in on AI, and the most sad rails conference of all times, where DHH declared how ruby on rails is de-facto dead (now it is all AI rust, baby).
Ruby really has a ton of problems. I'll not repeat them here all, but https://po-ru.com/2026/10/18/why-im-no-longer-updating-this-... summarized it nicely. With Claude being the new de-facto language designer, it may be best to completely re-think ruby. I do not see ruby having a future as agentic AI slop surrogate. It will just further accelerate decay against humans here, which is a problem other projects also suffer. You can find that on many comments - it is a real problem now. If you have two humans, and one claude slops all the time, and even uses claude to "interact" with other humans, you no longer communicate really. You kind of claude-cell isolated yourself.
I am not saying this is the case for all claude users, since some understand the problem domain - but many others do not understand that this is a real problem, which is shocking. Paul kind of understood the emerging problem here.