From: "Guy N. Hurst" Date: 2002-04-06T14:14:45+09:00 Subject: Re: Is eval a code/design smell? 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. ... 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? 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. Guy N. Hurst