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


 

Forums >

comp.lang.ruby

Re: Yield should be renamed call_block

Yukihiro Matsumoto

7/9/2007 12:07:00 PM

Hi,

In message "Re: Yield should be renamed call_block"
on Mon, 9 Jul 2007 19:17:13 +0900, dblack@wobblini.net writes:

|> I am not going to rename it. But in far future (3.0? maybe), the
|> keyword will be removed from the language, and you will access blocks
|> via block arguments of methods.
|
|I'm curious what the rationale is for that. Also, will the block
|syntax be removed, in favor of Proc arguments?

The code

def ntimes(n)
n.times do
yield
end
end

would go like this

def ntimes(n, &b)
n.times do
b.yield
end
end

Rationals are:

* you can detect methods that don't take blocks, that
currently ignored silently.
* we can make yield sementics bit simpler.

The former is more prefereable.

matz.
19 Answers

Martin DeMello

7/9/2007 1:08:00 PM

0

On 7/9/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
>
> def ntimes(n, &b)
> n.times do
> b.yield
> end
> end

It reads wrong, now, though - the block isn't yielding, the current
method is yielding *to* the block. #run might be a better method name.

martin

Bertram Scharpf

7/9/2007 1:14:00 PM

0

Hi,

Am Montag, 09. Jul 2007, 21:06:58 +0900 schrieb Yukihiro Matsumoto:
> [...] would go like this
>
> def ntimes(n, &b)
> n.times do
> b.yield
> end
> end

s/yield/call/

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-...

Robert Dober

7/9/2007 1:22:00 PM

0

On 7/9/07, Bertram Scharpf <lists@bertram-scharpf.de> wrote:

>
> s/yield/call/
>
> Bertram

I am with Bertram here, #call is describing what is done here.

Robert
--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

John Joyce

7/9/2007 1:27:00 PM

0


On Jul 9, 2007, at 7:06 AM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Yield should be renamed call_block"
> on Mon, 9 Jul 2007 19:17:13 +0900, dblack@wobblini.net writes:
>
> |> I am not going to rename it. But in far future (3.0? maybe), the
> |> keyword will be removed from the language, and you will access
> blocks
> |> via block arguments of methods.
> |
> |I'm curious what the rationale is for that. Also, will the block
> |syntax be removed, in favor of Proc arguments?
>
> The code
>
> def ntimes(n)
> n.times do
> yield
> end
> end
>
> would go like this
>
> def ntimes(n, &b)
> n.times do
> b.yield
> end
> end
>
>
the '&' sigil is kind of scary. Reminds me of C. I'd be disappointed
to see Ruby get more sigils.

James Gray

7/9/2007 1:30:00 PM

0

On Jul 9, 2007, at 8:27 AM, John Joyce wrote:

>
> On Jul 9, 2007, at 7:06 AM, Yukihiro Matsumoto wrote:
>
>> Hi,
>>
>> In message "Re: Yield should be renamed call_block"
>> on Mon, 9 Jul 2007 19:17:13 +0900, dblack@wobblini.net writes:
>>
>> |> I am not going to rename it. But in far future (3.0? maybe), the
>> |> keyword will be removed from the language, and you will access
>> blocks
>> |> via block arguments of methods.
>> |
>> |I'm curious what the rationale is for that. Also, will the block
>> |syntax be removed, in favor of Proc arguments?
>>
>> The code
>>
>> def ntimes(n)
>> n.times do
>> yield
>> end
>> end
>>
>> would go like this
>>
>> def ntimes(n, &b)
>> n.times do
>> b.yield
>> end
>> end
>>
>>
> the '&' sigil is kind of scary. Reminds me of C. I'd be
> disappointed to see Ruby get more sigils.

That's nothing new for Ruby. It works today. It's also needed.
Without it, it wouldn't be possible to save a block into a variable
for later use.

James Edward Gray II

Simen

7/9/2007 1:34:00 PM

0

On 7/9/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:
> the '&' sigil is kind of scary. Reminds me of C. I'd be disappointed
> to see Ruby get more sigils.
>
>
>

What are you talking about? The &-sigil in the argument list isn't a
proposed change, it's there already, so Ruby wouldn't be getting any
more sigils.

As for the aliasing yield-thing, it can't be done in Ruby, because it
depends on the local scope (maybe with hacks such as
Binding.of_caller, I'm not sure) . You'd need to inspect the stack,
which can't be done in Ruby and would rely on implementation details
in C. It just isn't worth it.

--
- Simen

Rob Biedenharn

7/9/2007 1:37:00 PM

0

On Jul 9, 2007, at 9:27 AM, John Joyce wrote:
> On Jul 9, 2007, at 7:06 AM, Yukihiro Matsumoto wrote:
>> Hi,
>>
>> In message "Re: Yield should be renamed call_block"
>> on Mon, 9 Jul 2007 19:17:13 +0900, dblack@wobblini.net writes:
>>
>> |> I am not going to rename it. But in far future (3.0? maybe), the
>> |> keyword will be removed from the language, and you will access
>> blocks
>> |> via block arguments of methods.
>> |
>> |I'm curious what the rationale is for that. Also, will the block
>> |syntax be removed, in favor of Proc arguments?
>>
>> The code
>>
>> def ntimes(n)
>> n.times do
>> yield
>> end
>> end
>>
>> would go like this
>>
>> def ntimes(n, &b)
>> n.times do
>> b.yield
>> end
>> end
>>
>>
> the '&' sigil is kind of scary. Reminds me of C. I'd be
> disappointed to see Ruby get more sigils.

That's already part of the language. You can use it right now to
capture the block associated to a method as a Proc that you can
manipulate. Using &block you'd test block.nil? in the same way that
you'd use block_given? when deciding to yield. If you change the
above code to be b.call, it works right now.

-Rob

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

dblack

7/9/2007 3:48:00 PM

0

dblack

7/9/2007 3:55:00 PM

0

Florian Groß

7/9/2007 9:51:00 PM

0

> Rationals are:
>
> * you can detect methods that don't take blocks, that
> currently ignored silently.

Currently, it is still possible for the method to check for blocks it
doesn't want by itself, though. (raise if block_given?)