From: Sean Middleditch <elanthis@...>
Date: 2002-04-05T09:14:01+09:00
Subject: Re: Is eval a code/design smell?

On Thu, 2002-04-04 at 17:32, Avi Bryant wrote:
> Sean Middleditch <elanthis@awesomeplay.com> wrote in message news:<1017933822.1548.12.camel@smiddle>...
> 
> > To me, that is indeed a language flaw.  There should be
> > methods that don't open up the security holes of eval() for
> > finding/setting attributes of an object.  Your specific need for no
> > initialize() still seems weird to me, but if it is necessary, and the
> > language restricts you from doing it, then either the language is flawed
> > or you are using the wrong langauge for the task.
> 
> Nonsense.  It's impossible to predict everything a language is going
> to be used for; the important thing is to make it extensible enough so
> that people can build whatever they need on top of it.  Is Ruby
> "flawed" because it doesn't ship with an XML parser? No, because you
> can write one in it.  Ruby lets you extend its base types, so any
> methods missing from those types can't be seen as flaws.  Moreover,
> Ruby provides eval, which is a very powerful way to build the added
> functionality you need.  If it didn't provide eval, and there was no
> way to add it, then you can start talking about flaws.  You're
> discussing a method that's 2 lines of Ruby or maybe 6 lines of C -
> does the requirement to write them make it the "wrong language for the
> task"??

You are right, of course.  There should be a way to make Ruby do what
you need, just like you can write an XML parser in Ruby.  For that same
reason, it should be possible to do everything eval() can do without
using eval().  Again, eval() is pretty much used by people for
dynamically looking up variables/members/methods.  That functionality
should be part of Ruby, in a way that doesn't use the inherent
insecurities of eval().  And since you can dynamically generate classes
and such in Ruby, that makes eval() even less necessary.

> 
> > People have built applications that do everything Ruby can do in C, and
> > done it faster than the Ruby interpreter could do it (although with a
> > lot more work than Ruby would require) without ever having an eval() for
> > C code.  ~,^
> 
> Turing tar pit.  So what - are you recommending we write everything in
> machine code?

Wow.  Talk about a change of context.

> And who says you can't eval C code?  Write it to disk, compile it into
> an .so, and load it.

Now, tell me why you would not do this?  I'm sure you can come up with
some very good reasons.  The same apply for taking arbitrary Ruby code,
dumping it to the parser, and loading that back and executing it fully
in the Ruby interpreter.  If you have the Ruby code already, you might
as well just load the code normally and not use eval().  If you are
dynamically generating code, you are probably doing things in a much
uglier way than you should be (and Ruby should/does provide the faster,
prettier ways of doing things).  Plus, if your code is at all based on
user input, you might as well have a way for the user to click on
"Delete the host's files" to save them from inputing the Ruby code to do
so.

> 
> Grumpily yours,
> Avi