I just wrote a little piece of code. Is it useful to anyone but
me? And/or do you see a more elegant way to do it, or any problems
with it?
I get tired of writing:
ENV[“this”] = x
y = ENV[“that”]
I’d rather write:
env.this = x
y = env.that
(Saving me brackets, quotes, and shift key.)
Here’s the code:
module EnvWrap
ENV.to_hash.each do |name,value|
newname = name.dup.downcase
define_method(newname) { ENV[name] }
define_method(newname+“=”) {|val| ENV[name] = val}
end
end
env = Object.new.extend EnvWrap
p env.path
env.path = “wocka”
p env.path
p ENV[‘PATH’]
Cheers,
Hal
That’s pretty useful! Why not generalize it though:
class Record
def initialize(source)
source.to_hash.each do |name, value|
method_name = name.downcase
define_method(method_name) { source[name] }
define_method(method_name + “=”) { |value| source[name] = value }
end
end
end
I don't like it. I have some environment variables with names like
"My-Env-Data". This is not a valid method name.
And i don't now what is the real benefit of your code ?
ENV['foo'] is in my opinion much more readable. And i never count the
time for typing my program. I write it once but read it many times.
I just wrote a little piece of code. Is it useful to anyone but
me? And/or do you see a more elegant way to do it, or any problems
with it?
Mentioned in other posts, it assumes that environmental variables are
uppercase. No biggie, most of them are. But I can’t resist throwing code
out, so what about something like this:
class WrapHash
def initialize(hash) @hash = hash
end
def method_missing(symbol, *args)
str = symbol.id2name
setter = str.sub!(/=$/, “”)
var = [str, str.upcase, str.downcase].detect { |key| @hash.include?(key) }
if setter @hash[var] = *args
else @hash[var]
end
end
end
I think that since we’re invoking methods explicitly,
it should still work if you remove the downcase stuff. It
shouldn’t get confused thinking caps are constants. Probably
won’t even have to add parens. I’ll test soon.
Hal
···
----- Original Message -----
From: “Jim Freeze” jim@freeze.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, August 21, 2003 3:32 PM
Subject: Re: Wrapping ENV
Hmm, not all env names are caps.
How does one access ENV[“fred”] vs ENV[“Fred”] vs ENV[“FRED”].
I don’t like it. I have some environment variables with names like
“My-Env-Data”. This is not a valid method name.
It’s useless for you then.
And i don’t now what is the real benefit of your code ?
ENV[‘foo’] is in my opinion much more readable. And i never count the
time for typing my program. I write it once but read it many times.
It’s even more useless for you, then.
It’s a question of taste. I do find it more readable as well as
easier to type. I’d rather simulate the environment as a struct
than a hash.
But of course there are significant problems with it.
And i don’t now what is the real benefit of your code ?
ENV[‘foo’] is in my opinion much more readable. And i never count the
time for typing my program. I write it once but read it many times.
If you like things much more readable and you never count the time for
typing I would suggest this code:
Why not make use of method_missing instead of defining methods for each
existing variable? The following code will work for existing variables as
well as let you add new ones.
class MyEnv
def method_missing(symbol, *args)
str = symbol.id2name
if args.length == 0
ENV[str]
else
ENV[str] = args[0].to_s
end
end
I don’t like it. I have some environment variables with names like
“My-Env-Data”. This is not a valid method name.
And i don’t now what is the real benefit of your code ?
Well it increases the signal to noise ratio of course
I find it very useful as a basis for some other uses (specialy like it
was later generalized). I haven’t yet seen anything about the remote ruby
project, but I came into ruby
willing to do domething similar (if the remote ruby project doesn’t already
do what I want, that is).
it’s very useful to “wrap” other objects, may it be a remote object, an ole
object or whatever wrapped object could make sense in your environment. you
make a generic base class which connects to the wrapped object and queries
it,
and instead of making its methods available through generic calls
(exec_method(method_name, blablabla)) you can
write wrapped_object.method_name(blabla), and now, the same with properties
and array properties should be possible, I’m still learning how to just
print hello world, but I was meaning to get in this direction as soon as
possible (and see if it’s even possible to do) this will save me a lot of
research
ENV[‘foo’] is in my opinion much more readable. And i never count the
time for typing my program. I write it once but read it many times.
That’s a good point, I don’t think I’d use this code for this particular
task either, but the code is still useful.
If you like things much more readable and you never count the time for
typing I would suggest this code:
THE_ENVIRONMENT_VARIABLES = ENV
verbosity != readable.
In fact your suggestion is much less readable. The normal mind can put
his focus on 7 items at a time. where ‘_’ separated parts of the identifier
counts as one. If this variable is used in a statement is is very
likely that it will increase the number of tokens over this magic
number.
If you like things much more readable and you never count the time for
typing I would suggest this code:
THE_ENVIRONMENT_VARIABLES = ENV
verbosity != readable.
In fact your suggestion is much less readable. The normal mind can put
his focus on 7 items at a time. where ‘_’ separated parts of the identifier
counts as one. If this variable is used in a statement is is very
likely that it will increase the number of tokens over this magic
number.
It was a joke. You snipped off the :)!! Dang, misquoted again.
