Re: Is eval a code/design smell?

Sean Middleditch <[e-mail]> wrote:

> If you are dynamically generating code, you are probably doing things in a
> much uglier way than you should be

I utterly disagree.  If you are *not* dynamically generating code, you
are either doing things in a much uglier way than you could be, or not
doing anything very interesting.  As I said in an earlier post, the
simplest example is attr_accessor.  Do you ever use it?  Do you
honestly believe that attr_accessor is uglier than writing out the
accessor methods by hand?  Ah, you say, but attr_accessor is a
"language feature" - all you're saying there is that matz is allowed
to use eval and the rest of us aren't.  My advice is, don't let
someone else tell you what abstractions you should use; build your
own.

I really can't stress this enough.  Find yourself writing the same
method over and over again, with slightly different names in different
contexts?  Pull it into a class method that generates it with
module_eval.  Have a large class hierarchy where each class has a
predictable structure?  Extract a list of the defining features of
each class and generate the rest.  The point here is what, when I'm in
academic mode, I call "Explicit Programming": the vocabulary used in
the source should, as closely as possible, match the vocabulary used
by the developers when talking about the system among themselves.  If
you can point to a class and say "that's an abstract factory for
Widgets", and that tells another developer all they need to know about
it, then *encode that same knowledge into your code*.  Sometimes this
can be done with type abstractions, which is great, but often, it
means writing a function that knows how to generate the code for you,
so that somewhere in your code you can have something like

abstract_factory(Widget, "WidgetFactory")

or maybe

class WidgetFactory < abstract_factory(Widget) end
I'll point again to Matju's X11 implementation as an excellent example
of this: his code reads like a straight specification of the protocol.
 It's beautiful.

If you want to read more, you can look at
http://www.cs.ubc.ca/~kdvolder/binaries/OOPSLA2001-EP-demo.pdf.  It's
a very short paper, the full length version of which is being
presented at Aspect Oriented Software Design this month, and which
I'll be able to post after the conference.

Cheers,
Avi