From: Sean Middleditch <elanthis@...>
Date: 2002-04-06T12:22:52+09:00
Subject: Re: Is eval a code/design smell?

You are missing the point entirely...

There is nothing wrong with dynamic code.  It's generating code, i.e.
the actual text passed to a parser and lexer, that I have the problem
with.

You can do everything you specified below *without* having to pass code
to the parser once the application is running - the language should
provide methods for building classes from components, components which
would have already been parsed and turned into bytecode/blocks.  I.e.,
if you have a block, you should be able to add that to a class as a
method, specifying arguments.  You should be able to build new methods,
as you said, in a generic fashion, and attach them to classes (which is
pretty much what mixins are, as is).

As for attr_accessor... I've never much liked them (but dealt with
them).  It would be, I think, more powerful and simpler to allow the
accessing of a member be mapped to calling a method (without "eval"ing
anything) in a generic manner, which could build even more powerful,
prettier looking, and more "interesting" code (which you seem to be
into).

Again, nothing you said requires an eval(), requires passing a string
into a parser to generate new blocks... all the actual, written code
should be already parsed - just in need of "assembling" (not in the
machine code fashion) into the proper form.

On Fri, 2002-04-05 at 03:33, Avi Bryant wrote:
> Sean Middleditch <elanthis@awesomeplay.com> 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