[bikeshed] Syntactic sugar idea

ruby-talk
1

It seems that often an object will be passed into a block only to invoke
a method of that object:
   arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
   arr.map{ .some_method }

Does that make any sense?

2

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }

Does that make any sense?

RUBY_VERSION

=> "1.9.1"

%w[foo bar baz].map(&:upcase)

=> ["FOO", "BAR", "BAZ"]

On Ruby 1.8.6, you can implement this easily as:

class Symbol
  def to_proc
    lambda { |x| x.send(self)
  end
end

-greg

···

On Wed, May 13, 2009 at 10:42 PM, Daniel DeLorme <dan-ml@dan42.com> wrote:

--
BOOK: http://rubybestpractices.com
TECH: http://blog.majesticseacreature.com
NON-TECH: http://metametta.blogspot.com

3

* Daniel DeLorme <dan-ml@dan42.com> [2009-05-14 11:42:31 +0900]:

It seems that often an object will be passed into a block only to invoke
a method of that object:
  arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
  arr.map{ .some_method }

You can do arr.map(&:some_method) in ruby 1.9

-J

···

Does that make any sense?

--
jan=callcc{|jan|jan};jan.call(jan)

4

Daniel DeLorme wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
  arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
  arr.map{ .some_method }

Does that make any sense?

It would be nice for avoiding instance_eval in DSLs:

@x = 400
@y = 300

config "my window" do
   .width @x
   .height @y
end

but I just don't see how to fit it into ruby...

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

5

I sometimes miss Perl's $_. Without a parser change, it could be used
as the default name for block parameters:

   arr.sort_by { $_.size }
   File.open("logfile", "a") { $_.puts logtext }
   arr.map { foo2bar($_) }

Then I remember how people abuse it and avoid using appropriately
named variables, and I am again happy about the little extra code I
have to write.

···

On Thu, May 14, 2009 at 4:42 AM, Daniel DeLorme <dan-ml@dan42.com> wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }

6

Daniel DeLorme wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
  arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
  arr.map{ .some_method }

Does that make any sense?

Groovy has this in the form of the "it" magic variable:

[1,2,3].each {puts it}

While I absolutely hate the moniker "it" the idea itself has grown on me. Perhaps something more scala-like:

[1,2,3].each {puts _}

Or a pseudo-global:

[1,2,3].each {puts $it}

I hacked "it" to work in JRuby once recently, and it's not difficult.

- Charlie

7

require 'enumerable/extra'

arr.map(:some_method)

Regards,

Dan

···

On May 13, 8:42 pm, Daniel DeLorme <dan...@dan42.com> wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }

8

Jan wrote:

* Daniel DeLorme <dan-ml@dan42.com> [2009-05-14 11:42:31 +0900]:

It seems that often an object will be passed into a block only to invoke
a method of that object:
  arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
  arr.map{ .some_method }

You can do arr.map(&:some_method) in ruby 1.9

Yes, I know, and that was kind of my point. The to_proc conversion
became popular because people want a shortcut notation for this common
case, but IMHO map(&:foo) is way uglier than map{.foo}, and as a bonus you could even do map{.foo.bar} :slight_smile:

-Daniel

9

Isn't this essentially the "with" syntax from Javascript? I think that could fit into a future version of Ruby...

- Josh

···

On May 14, 2009, at 12:27 AM, Joel VanderWerf wrote:

Daniel DeLorme wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }
So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }
Does that make any sense?

It would be nice for avoiding instance_eval in DSLs:

@x = 400
@y = 300

config "my window" do
.width @x
.height @y
end

but I just don't see how to fit it into ruby...

10

I sometimes miss Perl's $_.

Not that I'm advocating its use, but... Ruby does support $_
for perl-like command line scripting:

$ ruby -ne 'puts "dollar_underscore is: #$_"' /usr/share/dict/words | head
dollar_underscore is:
dollar_underscore is: A
dollar_underscore is: A's
dollar_underscore is: AOL
dollar_underscore is: AOL's
dollar_underscore is: Aachen
dollar_underscore is: Aachen's
dollar_underscore is: Aaliyah
dollar_underscore is: Aaliyah's
dollar_underscore is: Aaron

Regards,

Bill

···

From: "Lars Christensen" <larschbelunktumdk@gmail.com>

11

This is a neat idea, but wouldn't it conflict with the "fluent
interface" construct? Using Joel's DSL example:

config "my window" do
   .width @x
   .height @y
end

if we changed it to

config "my window" do
   .width calculate_width
   .height @y
end

Now how does the parser know what .height refers to: calculate_width,
or the implicit block variable?

12

Forget the $ and you are spelling out a thought I was bearing with me
for quite some time, ty Daniel and Joel to bring this up :).
I always wanted an implicit _ parameter in blocks, as e.g.
3.times do puts _ end

···

On Thu, May 14, 2009 at 11:33 AM, Lars Christensen <larschbelunktumdk@gmail.com> wrote:

On Thu, May 14, 2009 at 4:42 AM, Daniel DeLorme <dan-ml@dan42.com> wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }

I sometimes miss Perl's $_. Without a parser change, it could be used
as the default name for block parameters:

arr.sort_by { $_.size }
File.open("logfile", "a") { $_.puts logtext }
arr.map { foo2bar($_) }

Then I remember how people abuse it and avoid using appropriately
named variables, and I am again happy about the little extra code I
have to write.

--
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, préparer des
outils, répartir les tâches, alléger le travail… mais enseigne aux
gens la nostalgie de l’infini de la mer.

If you want to build a ship, don’t herd people together to collect
wood and don’t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

--
Antoine de Saint-Exupéry

13

Cool! What would it take to make this 1.9 compatible?

···

On May 14, 6:31 pm, Daniel Berger <djber...@gmail.com> wrote:

On May 13, 8:42 pm, Daniel DeLorme <dan...@dan42.com> wrote:

> It seems that often an object will be passed into a block only to invoke
> a method of that object:
> arr.map{ |obj| obj.some_method }

> So I had the (weird? stupid?) thought that it would be nice to have some
> syntactic sugar like this:
> arr.map{ .some_method }

require 'enumerable/extra'

arr.map(:some_method)

Regards,

Dan

14

I don't know. I think they're about the same in terms of looks, and
the former doesn't require changes to the parser.

-greg

···

On Wed, May 13, 2009 at 11:03 PM, Daniel DeLorme <dan-ml@dan42.com> wrote:

Yes, I know, and that was kind of my point. The to_proc conversion
became popular because people want a shortcut notation for this common
case, but IMHO map(&:foo) is way uglier than map{.foo}, and as a bonus you
could even do map{.foo.bar} :slight_smile:

15

Mark Thomas wrote:

This is a neat idea, but wouldn't it conflict with the "fluent
interface" construct? Using Joel's DSL example:

config "my window" do
   .width @x
   .height @y
end

if we changed it to

config "my window" do
   .width calculate_width
   .height @y
end

Now how does the parser know what .height refers to: calculate_width,
or the implicit block variable?

Yeah, seems impossible. Maybe if there were some other character instead of "." to signify sending a message to the block's "default object".

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

16

Mmm losing the $ would then render RSpec completely inoperable since
it has an it method.

--Jeremy

···

On Thu, May 14, 2009 at 9:46 AM, Robert Dober <robert.dober@gmail.com> wrote:

On Thu, May 14, 2009 at 11:33 AM, Lars Christensen > <larschbelunktumdk@gmail.com> wrote:

On Thu, May 14, 2009 at 4:42 AM, Daniel DeLorme <dan-ml@dan42.com> wrote:

It seems that often an object will be passed into a block only to invoke
a method of that object:
arr.map{ |obj| obj.some_method }

So I had the (weird? stupid?) thought that it would be nice to have some
syntactic sugar like this:
arr.map{ .some_method }

I sometimes miss Perl's $_. Without a parser change, it could be used
as the default name for block parameters:

arr.sort_by { $_.size }
File.open("logfile", "a") { $_.puts logtext }
arr.map { foo2bar($_) }

Then I remember how people abuse it and avoid using appropriately
named variables, and I am again happy about the little extra code I
have to write.

Forget the $ and you are spelling out a thought I was bearing with me
for quite some time, ty Daniel and Joel to bring this up :).
I always wanted an implicit _ parameter in blocks, as e.g.
3.times do puts _ end

--
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, préparer des
outils, répartir les tâches, alléger le travail… mais enseigne aux
gens la nostalgie de l’infini de la mer.

If you want to build a ship, don’t herd people together to collect
wood and don’t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

--
Antoine de Saint-Exupéry

--
http://jeremymcanally.com/
http://entp.com/

My books:

http://humblelittlerubybook.com/ (FREE!)

17

plus, doing your .foo.bar has to contend with .foo being nil (or otherwise having a NoMethodError for :bar)

some_collection.map{|e|e.foo.bar}

really isn't too bad anyway and if you want to handle the possible exception:

some_collection.map{|e|e.foo.bar rescue nil}

possibly with a .compact thrown on the end.

The parser already refused to treat .5 as a Float literal insisting that it be 0.5 so I doubt that .foo would get any more favorable treatment as a special case (since .5 isn't really all that special).

-Rob

Rob Biedenharn http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

···

On May 13, 2009, at 11:07 PM, Gregory Brown wrote:

On Wed, May 13, 2009 at 11:03 PM, Daniel DeLorme <dan-ml@dan42.com> > wrote:

Yes, I know, and that was kind of my point. The to_proc conversion
became popular because people want a shortcut notation for this common
case, but IMHO map(&:foo) is way uglier than map{.foo}, and as a bonus you
could even do map{.foo.bar} :slight_smile:

I don't know. I think they're about the same in terms of looks, and
the former doesn't require changes to the parser.

-greg

18

Rob Biedenharn wrote:

The parser already refused to treat .5 as a Float literal insisting that it be 0.5 so I doubt that .foo would get any more favorable treatment as a special case (since .5 isn't really all that special).

Well, you never know... Matz *did* add the Symbol#to_proc conversion in
1.9 and also the foo\n.bar "fluent interface" syntax. So apparently
trivial changes *do* make their way into core... sometimes.

-Daniel

19

But Symbol#to_proc is not a parser change. It's just using an existing
hook that has been around in Ruby 1.8

-greg

···

On Thu, May 14, 2009 at 12:16 AM, Daniel DeLorme <dan-ml@dan42.com> wrote:

Rob Biedenharn wrote:

The parser already refused to treat .5 as a Float literal insisting that
it be 0.5 so I doubt that .foo would get any more favorable treatment as a
special case (since .5 isn't really all that special).

Well, you never know... Matz *did* add the Symbol#to_proc conversion in
1.9 and also the foo\n.bar "fluent interface" syntax. So apparently
trivial changes *do* make their way into core... sometimes.

20

Gregory Brown wrote:

···

On Thu, May 14, 2009 at 12:16 AM, Daniel DeLorme <dan-ml@dan42.com> wrote:

Well, you never know... Matz *did* add the Symbol#to_proc conversion in
1.9 and also the foo\n.bar "fluent interface" syntax. So apparently
trivial changes *do* make their way into core... sometimes.

But Symbol#to_proc is not a parser change. It's just using an existing
hook that has been around in Ruby 1.8

But the fluent interface change *is* a parser change. My point was just that seemingly trivial requests *can* make it into the core, whether they're a syntax change or not.

-Daniel