but no metaprogramming, no decorators/ directory, no new concepts, only standard plain Rails. As a bonus it's even an instance of functional programming.
arthurlewis · 15h ago
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.
berkes · 22h ago
What annoys me (only slightly) in the Ruby community, is it's loose and often "wrong" usage of design patterns.
IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff. So that when someone, regardless of language, says "use an abstract factory" we know what it does, how it can be used, what it doesn't do, it's pitfalls etc.
What ruby calls "decorators" aren't "decorators". That's for this DIY implementation, but even more so for "Draper".
It's not only that an actual Decorator should not introduce new methods, but also how it's set-up and used. And therefore, what it's pitfalls and downsides are.
In the case of Draper or this DIY: the views now rely on a concrete and specific subclass - losing both LSP and DIP. Worse: the layer using it -views- aren't the one setting it up or controlling it - the controllers. So it introduces very hard dependencies between different domains - the views/partials/serializers now depend on whether or not you've remembered to actually decorate the model. Something that in my experience will go wrong and will crash in production - or if you're lucky and have lots of E2E tests, in CI.
The same "imprecise use of design patterns" happen with MVC, Models, ActiveRecord, "interfaces" and so forth. Often because of limitations of Ruby, but rather often because the Ruby community just uses the term "wrong".
arthurlewis · 36m ago
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.
RangerScience · 5h ago
> 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.
baobun · 22h ago
> 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.
berkes · 20h ago
Ruby doesn't have "interfaces" - obviously, because it doesn't have types or a type-enforcement.
So any design pattern, architecture or concept that relies on types, or interfaces, are "limited" in that sense. Ports, Adapters, Strategy, for example "
require" interfaces in their definition. Their benefits rely on interfaces, so if a language lacks this, you really only get the downsides. Factory, Observer, Decorators, etc mention them, and use them, but can be implemented without them.
Maybe "limitations" isn't the best word, because e.g. "an interface" is a deliberate limitation, imposed and designed by the developer.
arthurlewis · 16h ago
> 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?
arthurlewis · 15h ago
OH WAIT I SEE IT I'M THINKING OF THE FACADE PATTERN. Yes, the Ruby community does tend to conflate Decorator, Facade, and Presenter in very confusing ways.
Fire-Dragon-DoL · 3h ago
I mean, the ruby community thinks of draper when they talk about Ruby's decorators, so they have a unified definition, even if it conflicts with the definition outside of ruby world
nsonha · 21h ago
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?
berkes · 20h ago
Yes, that's very much how the Rails community thinks about "decorators": something that "decorates" the UI elements.
estsauver · 1d ago
Doesn't this thrash the ruby VM's virtual method cache? (It's been ~7 years since I was working on production ruby code, but I remember it being a really painful performance issue for us when using dynamic method missing routing. I might be getting it confused with class extensions though.)
byroot · 21h ago
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.
julienbourdeau · 23h ago
Very good question! The docs doesn't mention anything (unlike OpenStruct for instance)
firecall · 1d ago
Maybe I'm doing it wrong, but I've regretted my previous choice of using the Draper Gem and Decorators when coming back to old projects.
I found Decorators just obscured display logic away in an inconvenient way.
RangerScience · 23h ago
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`)
inopinatus · 1d ago
consisting of:
1. spend 30 minutes beating around the bush, reinventing the wheel etc for your own education and interest; then
2. throw that away and use SimpleDelegator from the standard library
and to be clear, I don’t mean this negatively at all.
pantulis · 1d ago
Sounds similar to begin building your own class and end up using an OpenStruct.
byroot · 21h ago
As a rule of thumb you never want to use OpenStruct. It's basically soft deprecated at this point because of its atrocious performance.
Holy... Is this better or worse than write-once perl regexes?
onli · 23h ago
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".
I don’t get how this works. Won’t the spaceship operator always return 1, 0, -1?
onli · 22h ago
Yes. And then clamp(0..) removes the -1, maps it to a 0. Why you'd want that? No idea.
mdoliwa · 22h ago
so this just says if we have free places or not?
students.size < maximum_number_of_students
jackbracken · 22h ago
It gives the number of free places, hinted by the method name `available_places`
Needlessly ugly way to write it imo though
vidarh · 21h ago
I think it probably made sense to the author because they've used all three (-1,0,1) for other examples, and would've been fine until separated out to a method reused to show the actual number.
I think they tried to be a bit too clever, basically.
onli · 22h ago
But it doesn't. The code will only ever output 0 or 1. With a regular <=> operator at least.
mdoliwa · 21h ago
yeah, so basically 1 we have available places, 0 we do not.
byroot · 21h ago
The `method_missing` signature isn't correct since Ruby 3.0, as it doesn't handle keyword arguments.
It should be:
def method_missing(name, *args, **kwargs, &block)
Starting from 3.1 it can be:
def method_missing(name, ...)
No comments yet
sathishmanohar · 23h ago
Wait. are we confusing decorator pattern where a Teacher can be AvailableTeacher or UnavailableTeacher with decorating the web page which is the role of view and view helpers?
No comments yet
lmz · 22h ago
Reminds me of this recent comment in another thread re: Rails:
IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff. So that when someone, regardless of language, says "use an abstract factory" we know what it does, how it can be used, what it doesn't do, it's pitfalls etc.
What ruby calls "decorators" aren't "decorators". That's for this DIY implementation, but even more so for "Draper".
It's not only that an actual Decorator should not introduce new methods, but also how it's set-up and used. And therefore, what it's pitfalls and downsides are.
In the case of Draper or this DIY: the views now rely on a concrete and specific subclass - losing both LSP and DIP. Worse: the layer using it -views- aren't the one setting it up or controlling it - the controllers. So it introduces very hard dependencies between different domains - the views/partials/serializers now depend on whether or not you've remembered to actually decorate the model. Something that in my experience will go wrong and will crash in production - or if you're lucky and have lots of E2E tests, in CI.
The same "imprecise use of design patterns" happen with MVC, Models, ActiveRecord, "interfaces" and so forth. Often because of limitations of Ruby, but rather often because the Ruby community just uses the term "wrong".
> 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.
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.
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.
So any design pattern, architecture or concept that relies on types, or interfaces, are "limited" in that sense. Ports, Adapters, Strategy, for example " require" interfaces in their definition. Their benefits rely on interfaces, so if a language lacks this, you really only get the downsides. Factory, Observer, Decorators, etc mention them, and use them, but can be implemented without them.
Maybe "limitations" isn't the best word, because e.g. "an interface" is a deliberate limitation, imposed and designed by the developer.
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?
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.
I found Decorators just obscured display logic away in an inconvenient way.
(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`)
1. spend 30 minutes beating around the bush, reinventing the wheel etc for your own education and interest; then
2. throw that away and use SimpleDelegator from the standard library
and to be clear, I don’t mean this negatively at all.
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".
Needlessly ugly way to write it imo though
I think they tried to be a bit too clever, basically.
It should be:
Starting from 3.1 it can be:No comments yet
No comments yet
https://news.ycombinator.com/item?id=44253645