Alternative to the Symbol#to_proc hack

[Ashley Moran]

I've always been in two minds about the Symbol#to_proc hack, it's
clever but adds a bit of line noise. Then I figured you can turn it
around:

class String
def everything_in(e)
e.map { |u| u.send(self) }
end
end

"upcase".everything_in %w( i am an array )

=> ["I", "AM", "AN", "ARRAY"]

It's a bit nasty because in 1.8 it can call private methods, but I
kinda like it. And it's not much use if you want to pass arguments
either.

Not sure if it's been done before either.

Ashley

 

[dblack]

Hi --

I've always been in two minds about the Symbol#to_proc hack, it's clever but
adds a bit of line noise. Then I figured you can turn it around:

class String
def everything_in(e)
e.map { |u| u.send(self) }
end
end

"upcase".everything_in %w( i am an array )

=> ["I", "AM", "AN", "ARRAY"]

It's a bit nasty because in 1.8 it can call private methods, but I kinda like
it. And it's not much use if you want to pass arguments either.

It seems a little odd to send a message to a string, and then have to
backtrack to the left, so to speak, and realize that the receiver of
the message is actually a message.... It actually feels to me like
it's entering the traditional realm of the class method:

String.upcase_all %w{ i am an array }

(Non-existent, but a typical class-method domain case.)

Of course, I'm hopelessly non-edge -- I actually think that:

%w{i am an array}.map {|item| item.upcase }

is logical, reads nicely left to right, and contains no line noise


David

--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black!

 

[Martin DeMello]

Hi --

you could do that neatly by trapping method_missing for String class
methods and matching against /^.*_all$/

martin

 

[Ashley Moran]

Of course, I'm hopelessly non-edge -- I actually think that:

%w{i am an array}.map {|item| item.upcase }

is logical, reads nicely left to right, and contains no line noise

True, but that only makes Java look old-fashioned. I wanted to make
Ruby look old-fashioned ;o)

Ever since I read about Higher-Order Messages at http://
nat.truemesh.com/archives/000537.html I've been determined to find a
way to write plain English as valid Ruby code. My goal is to find a
neat way to express business rules in Ruby, with as little framework
coding as possible. I think it may take a *little* more than
extending the String class though!

Ashley

 

[dblack]

Hi --

True, but that only makes Java look old-fashioned. I wanted to make Ruby
look old-fashioned ;o)

Hmmmm... I'm still rather fond of Ruby, I have to admit

Ever since I read about Higher-Order Messages at
http://nat.truemesh.com/archives/000537.html I've been determined to find a
way to write plain English as valid Ruby code. My goal is to find a neat way
to express business rules in Ruby, with as little framework coding as
possible. I think it may take a *little* more than extending the String
class though!

Beware the dot, though. It can give you English, but at the expense
of Ruby style. When I see:

x = half.of.the.first.item.in(container)

I want to know, and understand, what the message "the" means to the
return value of a call to "of" -- and it isn't easy. Of course it's
all legal Ruby, and can be documented... but it really sails beyond
the horizon of what i would consider reasonable use of method-call
syntax. In fact it's often a case of method-call syntax being used
for method-*name* semantics.


David

--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black!

 

[Ashley Moran]

Beware the dot, though. It can give you English, but at the expense
of Ruby style. When I see:

x = half.of.the.first.item.in(container)

I want to know, and understand, what the message "the" means to the
return value of a call to "of" -- and it isn't easy. Of course it's
all legal Ruby, and can be documented... but it really sails beyond
the horizon of what i would consider reasonable use of method-call
syntax. In fact it's often a case of method-call syntax being used
for method-*name* semantics.

David

That's a good point I hadn't considered. I don't know what to think
really. On the one had, I like code that is readable in the sense
that you can see what it does; on the other, I like to read code
where I can see *how it does it*. I think the former usually wins
though, or we'd all be programming in assembly.

Rails has got a lot of people using Ruby tricks that they don't fully
understand (eg collecting hashes and arrays in method definitions).
We're just starting to use it where I work, and first developer has
had to dive in and use Rails with only a token understanding of
Ruby. (Maybe I'm just weird - I prefer to understand how singleton
classes and method rewriting work before I go headfirst into crazy
stuff like Hello World!)

It's good that Ruby can be made so readable that you don't *need* to
understand it in depth to do useful stuff, but I think it will be the
undoing of many a newbie as they move to more ambitious projects.
I'm crossing my fingers that Rails doesn't become to web database
apps what Access is to desktop database apps! (What a terrible
thought to go to bed on...)

Ashley

 

[dblack]

Hi --

David

That's a good point I hadn't considered. I don't know what to think really.
On the one had, I like code that is readable in the sense that you can see
what it does; on the other, I like to read code where I can see *how it does
it*. I think the former usually wins though, or we'd all be programming in
assembly.

Maybe... though much of what I like about Ruby is how those two things
usually mesh so nicely. The serial.dot.style obscures the "how", and
does so unnecessarily in my opinion.

Rails has got a lot of people using Ruby tricks that they don't fully
understand (eg collecting hashes and arrays in method definitions). We're
just starting to use it where I work, and first developer has had to dive in
and use Rails with only a token understanding of Ruby. (Maybe I'm just weird
- I prefer to understand how singleton classes and method rewriting work
before I go headfirst into crazy stuff like Hello World!)

What a coincidence -- I wrote my book precisely for weird people like
you who want to know what they're doing

It's good that Ruby can be made so readable that you don't *need* to
understand it in depth to do useful stuff, but I think it will be the undoing
of many a newbie as they move to more ambitious projects.

The low entry barrier is definitely both a blessing and a curse -- the
latter in the sense that it can make people think either (a) there's
nothing more to learn; it's all quickly available, or (b) there might
be more to learn but the easy part is over and the rest will be really
hard. Happily, neither is true; the truth is that there's a lot left
to learn and understand, and if done correctly it's quite accessible.

I'm crossing my fingers that Rails doesn't become to web database
apps what Access is to desktop database apps! (What a terrible
thought to go to bed on...)

When I wrote "Ruby for Rails", I was thinking a lot about the
precedent of the role of CGI programming in the Perl world -- namely,
that it's one of the greatest manifestations of Perl and, at the same
time, a bottomless swamp of misunderstanding and misuse of the
language. I wanted to make sure nothing similar, comparable, or even
analogous happened as between Ruby and Rails. Mind you, I don't think
we were ever in danger of wholesale Perl/CGI-style script kiddiness.
But there's definitely scope for either knowing or not knowing what
one is doing, and like you I tend to prefer and encourage the former



David

--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black!

 

[M. Edward (Ed) Borasky]

I'm crossing my fingers that Rails doesn't become to web database apps
what Access is to desktop database apps! (What a terrible thought to
go to bed on...)

Access is great until your database gets a byte or 2 bigger than 2 GB.

 

[Daniel DeLorme]

"upcase".everything_in %w( i am an array )

=> ["I", "AM", "AN", "ARRAY"]

That's nice for map, but the to_proc hack can apply to ANY method. For example:
%w( i am an array ).sort_by(&:reverse)

Daniel