
The Ruby Module Builder Pattern - shioyama
http://dejimata.com/2017/5/20/the-ruby-module-builder-pattern
======
fishnchips
I'm familiar with dry-rb coding style and I think it is very difficult to
reason about. Metaprogramming often feels like magic but it comes at a price -
hard for newbies to grok and impossible for static tools to work with. I would
only advise using it (if at all) in well-tested libraries that expose a well-
documented public API.

~~~
ashark
I'm immediately put off by any system that doesn't let me figure out WTF
something actually is until runtime. I should be able to learn most of what I
need to know about a codebase with a basic text editor and grep. Some
questions should be for documentation to answer, but "what the _hell_ is this
variable representing?" isn't one of them.

I prefer to let my code and my tools remember stuff for me. Rails and
similarly-magical Ruby systems have too high a (human) memory overhead for my
taste. Hard to jump in and out of if it's not the main thing you do every day.

~~~
ooqr
I think Rails does a pretty good job of making well-documented sense. Lots of
crappy gems abuse things like implicit global variables, rewriting core
methods, and other monstrous applications of metaprogramming.

------
thomasfedb
I'm an experienced Rubyist who's done their fair share of horrible hacky
things.

This is quite nice. It avoid some of the issues that other metaprograming
techniques will land you, and the associated debugging hell.

Nicely written too.

------
cutler
This article demonstrates the mess you can get into when you mix OOP with
metaprogramming and why Ruby has a bad reputation for encouraging it.
Metaprogramming seems to compound the contortions of OOP in contrast to the
elegance macros add to functional languages like Clojure and Elixir. Ruby's
method_missing and instance_eval seem like ugly hacks compared with the simple
quote/unquote of Lisp-based languages.

~~~
shioyama
Author here. As a longtime fan of Scheme and Lisp-based languages in general,
I take responses like this very seriously. I'm not a huge fan of
method_missing, and in practice I don't use it terribly often, but it has its
place.

That said, the article is about something quite minimal in terms of
metaprogramming: subclassing a class (Module), which would itself not be
defined as metaprogramming at all, and then defining some methods on it in an
initializer. I don't find this very convoluted at all: you're creating a
prototype for a module which can be configured to use in a variety of
contexts.

I wrote this article _after_ having used this pattern in a very practical
context (designing Mobility) to solve a very concrete problem: abstracting
storage solutions (backends) from the interface for translating content. I
found it to be a very concise and elegant solution in this context. I think a
project like Rails would benefit in several places by adopting this pattern
since it would actually _simplify_ a lot of the code which already uses
anonymous modules (basically the same mechanism) but in a very hard-to-
understand way.

Comparisons to other languages like Clojure and Elixir bring with them a whole
slew of other questions, since the languages are entirely different. I'd
prefer to focus on Ruby itself and what the alternatives are _within this
language_ , and for the use case discussed I strongly believe Module Builder
is the optimal solution, not a "mess" at all.

------
p4lindromica
At first pass, this looks very similar to the typeclass pattern in Scala

------
clairity
i like the hand-drawn class diagrams. =)

i wish there were more of these (ruby) metaprogramming articles, since there
is a lot of ingenuity going on under the covers.

it's just like jargon in specialized fields - so much is packed into so few
symbols. it allows those who understand it to express more complex ideas more
easily but also serves as a barrier to those unfamiliar with the jargon.

~~~
godd2
The drawings are reminiscent of the diagrams in Metaprogramming Ruby, which is
definitely worth the read if you want to dig into it.

It's much easier to read than you might think.

~~~
shioyama
This was actually the inspiration for them :)

