On Nov 9, 10:30 am, "ara.t.howard" <ara.t.how... / gmail.com> wrote:
> On Nov 9, 2007, at 5:55 AM, furtive.cl... / gmail.com wrote:
>
> > Thanks for the response.  Actually I previously abandoned this kind of
> > setup because it was inconsistent with the rest of my rakefile.  I
> > don't want a clear distinction between config variables and regular
> > variables --- in fact, the blurrier the better.  If I decide to move
> > one variable into the config section, there should be no associated
> > code changes.
>
> sounds very confusing to maintain to me, but it's your party
>

Well it's the opposite.  Having to adjust the syntax of each mention
of a variable just because you moved the variable into a config file
is confusing to maintain.

>
> > One solution is to put all my variables in that config class,
> > whereupon I would call it class Stuff.  But then the rakefile is
> > messier and harder to manage: "s.foo ; s.bar ;" instead of "foo ;
> > bar ;".  I can avoid these "s." prefixes by putting everything inside
> > an instance_eval, but then I am back to exactly the same problem I had
> > in my second post in this thread.  Namely, "foo = 99" creates a local
> > variable 'foo' instead of calling Stuff#foo=, whereupon I have two
> > 'foo's and all hell breaks loose.
>
> not so, attributes allows a default block and getter as setter.  so
> you don't need to say
>
>    s.foo = 99
>
> just
>
>    foo 99
>

But like I said above, it's a maintenance problem.  Setting some
variables with "foo 99" and others with "bar = 88" is confusing.  When
I decide to place bar in a config file, I have to change all mentions
of "bar = blah" to "bar blah".  Not using local variables at all would
achieve consistency but would introduce a different flavor of
confusion.

> you cannot set a local variable via eval

Not so:

   val = nil
   eval "val = 12"
   p val # => 12