3 ms·

As most other commenters have similarly said, this blog post should be a single word: "Don't". The book "Eloquent Ruby" has several chapters on how to use "met

As most other commenters have similarly said, this blog post should be a single word: "Don't". The book "Eloquent Ruby" has several chapters on how to use "method_missing". None of those chapters say the only valid use of method_missing: "Never use it." Lots of languages have deep flaws. Javascript, Python, Java, Perl, C obviously, all let you do some pretty horrific stuff if you really want to. Ruby is the only language where the horror is embraced by the ecosystem and its users. There's a reason most engineers are adamant you shouldn't use this. It's why learning Ruby as your first language is probably a bad idea, since it normalizes what every other language has agreed is bad practice. Don't!

quechimba 3y ago
method_missing is great if you're wrapping an object class Wrapper < BasicObject def initialize(obj) @obj = obj end def method_missing(name, *, **, &) ::Kernel.puts "Calling #{name}" @obj.send(name, *, **, &) end end
- deleted 3y ago
  [deleted]
- psychoslave 3y ago
  You can use Delagator for that https://ruby-doc.org/stdlib-3.1.0/libdoc/delegate/rdoc/Delegator.html https://ruby-doc.org/stdlib-3.1.0/libdoc/delegate/rdoc/Deleg...
masa331 3y ago
When i was around 20 i learned Ruby as basically my first language and it has been a joyride ever since. I had a chance to develop and co-develop things in other languages but for me there is none matching speed, joy and effectivity of Ruby. Everyone's mileage may vary but i definitelly do recommend learnign Ruby as a first leanguage. What i also recommend starting developers is to not follow dogmatic advices blindly.
dgb23 3y ago
I don’t know Ruby but I’ve been a huge fan of Lisp macros (Clojure). As with all abstraction mechanisms, you avoid them until you need them. When you do need them, they become a force multiplier. A lot of macros can be avoided with data driven programming, which is likely one of the strongest techniques in terms of cost/benefit. A light form of meta programming is source code generation (often used in tandem with data driven). It lets you have macro-like power, but the guts are spilled out for you to modify further or reason about easily. In some languages it’s the only thing you can do at that abstraction level. In any case, meta programming is very powerful. But its quality and utility hinges on you to avoid it until you exhaust all of the lower level techniques. Else you end up with the worst kind of wrong abstraction.
x86x87 3y ago
Yeah no. There are times when it's useful. I think most of the times you don't need it but you coming in and saying don't use it sounds a bit pretentious. Ruby does not have to do what other languages are doing. There is no good or bad. Do you have any stories? Tried using it and it backfired? Were bitten by a nasty bug in a gem?
goatlover 3y ago
Do! When the need arises. Language designers wouldn't include such facilities if there was never a need. Ruby is hardly alone in this. I can't imagine a Lisper ever saying never use macros. C++ has templates, Rust has macros, Python has magic methods, metaclasses and decorators. Javascript, Java, Perl, C let you do some pretty horrific stuff because sometimes you need the the flexibility. If you look at enough library and framework code, you will see those things in use. Don't! Be dogmatic about programming. There are always use cases.

quechimba 3y ago

method_missing is great if you're wrapping an object class Wrapper < BasicObject def initialize(obj) @obj = obj end def method_missing(name, *, **, &) ::Kernel.puts "Calling #{name}" @obj.send(name, *, **, &) end end

deleted 3y ago
[deleted]
psychoslave 3y ago
You can use Delagator for that https://ruby-doc.org/stdlib-3.1.0/libdoc/delegate/rdoc/Delegator.html https://ruby-doc.org/stdlib-3.1.0/libdoc/delegate/rdoc/Deleg...

masa331 3y ago

When i was around 20 i learned Ruby as basically my first language and it has been a joyride ever since. I had a chance to develop and co-develop things in other languages but for me there is none matching speed, joy and effectivity of Ruby. Everyone's mileage may vary but i definitelly do recommend learnign Ruby as a first leanguage. What i also recommend starting developers is to not follow dogmatic advices blindly.

dgb23 3y ago

I don’t know Ruby but I’ve been a huge fan of Lisp macros (Clojure). As with all abstraction mechanisms, you avoid them until you need them. When you do need them, they become a force multiplier. A lot of macros can be avoided with data driven programming, which is likely one of the strongest techniques in terms of cost/benefit. A light form of meta programming is source code generation (often used in tandem with data driven). It lets you have macro-like power, but the guts are spilled out for you to modify further or reason about easily. In some languages it’s the only thing you can do at that abstraction level. In any case, meta programming is very powerful. But its quality and utility hinges on you to avoid it until you exhaust all of the lower level techniques. Else you end up with the worst kind of wrong abstraction.

x86x87 3y ago

Yeah no. There are times when it's useful. I think most of the times you don't need it but you coming in and saying don't use it sounds a bit pretentious. Ruby does not have to do what other languages are doing. There is no good or bad. Do you have any stories? Tried using it and it backfired? Were bitten by a nasty bug in a gem?

goatlover 3y ago

Do! When the need arises. Language designers wouldn't include such facilities if there was never a need. Ruby is hardly alone in this. I can't imagine a Lisper ever saying never use macros. C++ has templates, Rust has macros, Python has magic methods, metaclasses and decorators. Javascript, Java, Perl, C let you do some pretty horrific stuff because sometimes you need the the flexibility. If you look at enough library and framework code, you will see those things in use. Don't! Be dogmatic about programming. There are always use cases.