The thing I like about the approach I took is that it doesn't
generalize to any other context. It only does one thing. I'm using it
in a constructor which takes a hash. Sometimes the hash is built by
code, and sometimes it's a params hash in Rails - in other words, a
set of Strings - with a few additional values merged in. It's pretty
common in Ruby to use a hash as a substitute for keyword arguments to
methods, and that's what's happening here. The code gets kind of
wiggy, and it makes it really nice when the params specified in a URL
or a form post line up exactly with the "keyword arguments" so that
there's no unnecessary synonyms clouding the semantic space. you
basically get semantic URLs this way internally to your application.
but if you want to use a boolean in this context, you have to convert
it, and circumvent that whole
if "false" # => true
gotcha.
this isn't actually related to human language **at all**. if you're
attempting to use URL parameters as keyword arguments, you want the
URLs to look just like Ruby, but of course the values in a URL or in
form parameters can actually only move out to the Web or come back
from it as strings. false doesn't come in as the string "false"
because I speak English. it comes in as the string "false" because
**Ruby** speaks English. if Ruby used the word "falso" or for that
matter "nothos," transliterating Ruby literals into strings would mean
using "nothos" or "falso" also. it's got nothing to do with locales.
it's got to do with being able to seamlessly transliterate your code
into URLs for the Web and get it back in executable form.
ok, apologies if that's somewhat defensive. I'm just saying, a lot of
the critiques sound dead on, but in this case I totally stand by my
design. in the broader case, I'm used to this from Perl, where the
scalar "false" also evaluates to true. but one of the huge strengths
of Ruby is that it keeps a lot of Perl's power and flexibility, but
throws away the weird, nearly demented idiosyncrasies. I can't be the
first person who ever coded a solution like this, and I know that
.to_i exists because your code can get numbers in as Strings or Floats
or what have you and need to convert it before doing anything real
with it.
(probably I should just STFU and package this up as a microgem or what
have you.)
anyway I think this is probably the answer:
I am thinking that, with people saying that they want to
have a wide assortment of what constitutes true, that they should
make a list (array) of things which would evaluate to true and
anything else would be false. But that is so individual that
making it part of the language seems counter productive.
I think the reason it's not part of the language is that you
**should** alter the language for specific things. I kind of
overloaded on Perl and went to Java and Python, and I actually found
the stability of those languages a nice change. so when I got into
Ruby, the idea of changing fundamental types for specific programs
seemed notorious and reckless, what the Pythonistas used to snort
derisively about and call "Perlish," but I'm thinking it's actually a
very sensible approach. you shouldn't view Ruby the language as
fundamental - you should view it as a **template** for the language
you're actually going to use once you fully define the problem space
and your corresponding solution. like the Paul Graham idea about Lisp,
that you build the program down to the language and build the language
up to the program, except a lot more of the work is already done for
you when you start.
···
--
Giles Bowkett
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
