Friendly attributes pattern in Ruby
brunosutic.com
Friendly attributes pattern in Ruby
1–10 of 78 posts
Re: Friendly attributes pattern in Ruby
#2Yikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
Re: Friendly attributes pattern in Ruby
#3Yikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
Yeah, this is honestly the sort of thing I grew to hate in Ruby. It looks cute, but all it does is create more cruft. Good ol’ boring keys are just fine, expressive enough, and are very unlikely to cause problems. This feels like it’s attempting to solve a problem that does not exist.
Re: Friendly attributes pattern in Ruby
#4I don't really like the API design. Perhaps in the rails-world this makes sense, but it looks really strange to me.
Billing::Plan::Factory.find_or_create_by!(
name: :pro,
interval: 1.month,
amount: 50
)
Re: Friendly attributes pattern in Ruby
#5Yikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
Yeah, this is honestly the sort of thing I grew to hate in Ruby. It looks cute, but all it does is create more cruft. Good ol’ boring keys are just fine, expressive enough, and are very unlikely to cause problems. This feels like it’s attempting to solve a problem that does not exist.
The advantage is the amount of code minimized and not using a generic factory pattern. But that probably can be achieved with a bit less magic...
Re: Friendly attributes pattern in Ruby
#6Yikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
Yeah, this is honestly the sort of thing I grew to hate in Ruby. It looks cute, but all it does is create more cruft. Good ol’ boring keys are just fine, expressive enough, and are very unlikely to cause problems. This feels like it’s attempting to solve a problem that does not exist.
> this is honestly the sort of thing I grew to hate in Ruby
But nobody forces you to use a DSL such as rails, so I am not sure why ruby should be hated for this when it is a rails dev who does that.
The blog has much more to do with rails than ruby; such API design is really strange.
I don't think this design causes problems as such, but it is too verbose and way too ugly. To me it seems that they are just shuffling data structures around; that could even be solved via yaml files.
Re: Friendly attributes pattern in Ruby
#7I don't really like the API design. Perhaps in the rails-world this makes sense, but it looks really strange to me. Billing::Plan::Factory.find_or_create_by!( name: :pro, interval: 1.month, amount: 50 ) It is not only the verbosity or use of trailing '!' in a method for no real reason, IMO, but also things such as "1.month". I understand that rails thrives as a DSL, but to me having a method such as .month on an Inte…
> I understand that rails thrives as a DSL, but to me having a method such as .month on an Integer, is simply wrong
It's not that different from `1.times` or `90.chr` which are vanilla Ruby.
> HashWithIndifferentAccess
HashWithIndifferentAccess was an unfortunate necessity to avoid DOS attacks when Symbols used to be immortal. There's no longer a reason to use it today, except for backward compatibility.
Re: Friendly attributes pattern in Ruby
#8Yikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
This is a philosophy. One which many people that write Ruby subscribe to. The fundamental idea is: create a DSL that makes it very easy to implement your application. It is what made Rails different when it was created: it is a DSL that makes expressing web applications easy.
I don't know its history well enough, but it seems to originate from Lisp. PG wrote about it before [1].
It can result in code that is extremely easy to read and reason about. It can also be incredibly messy. I have seen lots of examples of both over the years.
It is the polar opposite of Go's philosophy (be explicit & favour predictability across all codebases over expressiveness).
Re: Friendly attributes pattern in Ruby
#9this is very unnecessary. Arrays and maps transformations are really easy and concise in core ruby already, one line of map, to_h or whatever.
Re: Friendly attributes pattern in Ruby
#10This is a perfect example of something that looks good in a demo but fails in a real product. Business logic and 'packages' are never this clean or simple.
Putting this kind of type-based 'magic' in the code is a bad decision that will bite you very soon. It optimizes for being 'cute' rather than being clear and maintainable, and that's a trade-off that almost never pays off.