Re: Is eval a code/design smell?

On Sat, 2002-04-06 at 00:14, Guy N. Hurst wrote:
> Sean Middleditch wrote:
> > ...
> > 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).
> > 
> 
> I think you would like Python, which takes this kind of erector-set approach.
> It has bytecode, attachment, and automatically-public member attributes
> which are accessed the same way a 'method' is.

If I liked Python better, I'd be bitching on Python's lists to add the
few Ruby features it's missing, instead of vice versa.  ^,^

> 
> ...
> 
> As for all the comments about 'eval' being evil, I totally disagree in the
> context of Ruby. I do believe it is bad in *other* languages, but in Ruby,
> eval and its siblings are natural and necessary. Ruby in particular is by
> its very nature so dynamic and integrated that using eval et. al. is hardly
> any different than not using it. Ruby seems to have perfected the concept
> of evaluating everything it comes across. It is said that in Ruby, "everything
> has its value". So why the big deal, why the hesitation to use eval?? Is it not
> because it was wise to avoid such a thing in other languages or situations?

Why, again, is it necessary to use eval() instead of the 'erector' set
approach above?  You said absolutely nothing that says eval() solves
problems the other way can't, and again failed to take into
consideration the security concerns.

> 
> I am firmly convinced that this should be explicitly pointed out to newcomers,
> that they should not shirk from using eval, module_eval, and instance_eval.
> Using them in Ruby is a sweet aroma, if anything.

^,^  I would, of course, say the newcomers should write their code
properly from the beginning, and not need to have Ruby strings parsed at
run time when the code could just as easily have been parsed at compile
time.

> 
> 
> Guy N. Hurst