Sounds similar to begin building your own class and end up using an OpenStruct.

Very good question! The docs doesn't mention anything (unlike OpenStruct for instance)

Not certain what you mean by "virtual method cache", the Ruby VM has multiple layers of method cache (or call cache) but I've never heard any of them referred to as the "virtual method cache".

For the inline call caches in the interpreter loop, they are monomorphic, so if you call the same codepath with the decorator and the actual object, they will indeed flip flop.

The second layer of cache is class based, so after the inline cache is defeated you will end up doing a single hash-table lookup on the class.

As for YJIT, IIRC it does handle polymorphic call caches, so it won't mind such situation at all unless you have more than a handful of different implementations of that method being called at a given callsite.

Might've been wise at the time, but nowadays I think the recommendation is to use View Components to package up view logic.

(I'm personally so-so on VCs; I think the core idea is pretty good but I'm not super sold on some of the implementation details - too OOP, not enough `yield`)

Well, until you need different `colour_coded_availability` methods for different contexts. Helpers get a lot done, but there are absolutely use cases for a separate presentation layer.

I don’t get how this works. Won’t the spaceship operator always return 1, 0, -1?

I started writing a comment wanting to defend it, because the expressions themselves are not that unreadable. <=> is a comparator (and used in many languages), clamp sets min and max sizes (and that can be guessed from the english meaning of the word), and 0.. is a range that goes from 0 to infinity (admittedly not that common an expression, but completely logical and intuitive way to express a range once you understood once that it is about ranges).

But then I realized that's nonsensical, and not what the code is supposed to do given the usage in the template. I assume something got mangled there when changing the code for the blog post.

Or I'm just understanding the ruby code wrong despite checking just now in irb, in that case that's a point for the intention of your comment, and a vote for "worse".

The same can be achieved with

  [maximum_number_of_students - students.size, 0].max

> Often because of limitations of Ruby

wat.

If anything I think Rubys lack of limitations could be the issue. There's a thousand different ways to do anything, and people do.

yeah I'm not familiar with rails and when I read this I was like what do they think a decorator is? Something that literally decorates with colors?

> It's not only that an actual Decorator should not introduce new methods

Maybe I'm misreading you, but I've never seen a definition of the Decorator pattern that doesn't involve new methods on the Decorator. If that's what you mean, can you say more? If not, what do you mean?

> IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff

To disagree - Design patterns are a communication language. You use them to talk about code; if you use them as strict recipes they become dogma, with all the problems that entails.

Beyond that - most of the canonical design patterns are coping mechanisms for the limitations of pre-modern Java / strict OOP. You just plain don’t need them in a language like Ruby - IMO, mostly because of ‘yeild’.

The “imprecise use” is a consequence of either trying to use an unnecessary design pattern, or trying too dogmatically to adhere to one.

Couldn’t get this idea out of my mind so I went back to the GoF text:

> Decorator subclasses are free to add operations for specific functionality. For example, ScrollDecorator’s ScrollTo operation lets other objects scroll the interface if they know there happens to be a ScrollDecorator object in the interface.