[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[bikeshed] Syntactic sugar idea

Daniel DeLorme

5/14/2009 2:43:00 AM

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?
24 Answers

Gregory Brown

5/14/2009 2:52:00 AM

0

On Wed, May 13, 2009 at 10:42 PM, 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:
> =A0arr.map{ |obj| obj.some_method }
>
> So I had the (weird? stupid?) thought that it would be nice to have some
> syntactic sugar like this:
> =A0arr.map{ .some_method }
>
> Does that make any sense?

>> RUBY_VERSION
=3D> "1.9.1"
>> %w[foo bar baz].map(&:upcase)
=3D> ["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

--=20
BOOK: http://rubybestpra...
TECH: http://blog.majesticseacr...
NON-TECH: http://metametta.bl...

Daniel DeLorme

5/14/2009 3:03:00 AM

0

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} :-)

-Daniel

Gregory Brown

5/14/2009 3:07:00 AM

0

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 yo=
u
> could even do map{.foo.bar} =A0:-)

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

Rob Biedenharn

5/14/2009 3:32:00 AM

0

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} :-)
>
> 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


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://agileconsult...
Rob@AgileConsultingLLC.com

Daniel DeLorme

5/14/2009 4:16:00 AM

0

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

Joel VanderWerf

5/14/2009 4:28:00 AM

0

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

Gregory Brown

5/14/2009 5:14:00 AM

0

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.

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

Joshua Ballanco

5/14/2009 5:20:00 AM

0

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...

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


- Josh

Daniel DeLorme

5/14/2009 6:08:00 AM

0

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

Robert Klemme

5/14/2009 7:16:00 AM

0

2009/5/14 Daniel DeLorme <dan-ml@dan42.com>:
> 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.

We always need to balance cost and benefit. In this case to me the
benefit seems to be outweighed by costs whereas the other change can
have an impact on readability. YMMV though.

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestprac...