From: Robert Klemme <shortcutter@...>
Date: 2010-10-08T17:40:17+09:00
Subject: Re: setting local variables in a binding

On Fri, Oct 8, 2010 at 6:06 AM, John Sikora <john.sikora@xtera.com> wrote:
> Robert Klemme wrote:
>> On Thu, Oct 7, 2010 at 4:19 AM, John Sikora <john.sikora@xtera.com>
>> wrote:
>>> I have sometimes seen 'local' or 'unassociated' instance variables (not
>>> sure if my terminology is correct)
>>
>> Not sure what you actually mean by that.
>
> I mean that I have seen examples where people use, say '@var', outside
> of any class, module, or method; in the 'main body' of the program. I
> would think that they would just use 'var' instead. I do not see why it
> would be advantageous to use '@var'. Is there a reason to do this?
>
>>> I use eval in personal scripts since it is so convenient. Had to go back
>>> and look at some code to remind myself how I got around the behavior
>>> seen in the first irb session. I don't remember if I read about using
>>> the local instance variable or just played around with it until I got it
>>> to work.
>>
>> What do you use eval for?  In cases where the set of variables is not
>> fixed at coding time chances are that you usually want a Hash.  Using
>> eval should be really be rare and for specific cases but not an
>> everyday habit IMHO.
>
> I mainly use 'eval' to evaluate syntactic sugar expressions for
> enumerable methods such as 'sort', 'find_all', 'all?', etc. I have
> created a Module with enumerable classes (they have an 'each' method)

So you have something like

class Foo
  def self.each
    yield "whatever"
    self
  end
end

?  Did you also do

class Foo
  def self.each
    yield "whatever"
  end

  extend Enumerable
end

?  That would give you all methods like #find_all etc. for free.

> and I have added syntactic sugar to some of the methods. So I can be
> lazy (and quick) and write things like:
>
> Slot.enum.find_all(‘:slot_num >= 8’, ‘:slot_num <= 22’, “:rate ==
> ‘ufec’”).all?(‘:errors == 0’)

Is this equivalent to

enum.find_all {|s| (8..22) === s.slot_num && s.rate == 'ufec'}.all?
{|s| e.errors == 0}

?  If yes, I do not really see the advantage of your approach.  It's
slower needs a similar amount of typing and will detect errors later
(at execution time vs. at parse time).

> As you can probably guess, anything with a ':' before it is an attribute
> that gets evaluated. Then the expression gets evaluated. I know I could
> use ‘send’ for the first evaluation, but sometimes I chain together
> attributes of attributes, use variables in the expressions, etc., and it
> gets more complicated. 'eval' is my easy way out (I’m just a hardware
> engineer trying to make my life easier). In case anyone is wondering,
> the parameters given in 'find_all' have the option of an ‘and’ or ‘or’
> function. Default is ‘and’ as in the example.

If my assumption above is correct I do not understand where the "easy
way out" is.

> Speed is generally not an issue and I am somewhat aware of the dangers
> of using 'eval'. I try to isolate the 'eval' expressions by limiting the
> user (me, mostly) to commands that have pre-programmmed options. A
> malicious user could probably find a way around it though since I am not
> too savvy in this area.
>
> I am always looking to improve the code and if anyone can suggest ways
> of eliminating the 'eval' statements while keeping the same
> functionality, I will certainly listen. I am also trying to read up on
> the latest dynamic techniques that rely less upon 'eval'.

(see above)

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/