[#407] New feature for Ruby? — Clemens.Hintze@...

Hi all,

27 messages 1999/07/01
[#413] Re: New feature for Ruby? — matz@... (Yukihiro Matsumoto) 1999/07/01

Hi Clemens,

[#416] Re: New feature for Ruby? — Clemens Hintze <c.hintze@...> 1999/07/01

On Thu, 01 Jul 1999, Yukihiro Matsumoto wrote:

[#418] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/01

Hi

[#426] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/02

Hi,

[#440] Now another totally different ;-) — Clemens Hintze <c.hintze@...>

Hi,

21 messages 1999/07/09
[#441] Re: Now another totally different ;-) — matz@... (Yukihiro Matsumoto) 1999/07/09

Hi,

[#442] Re: Now another totally different ;-) — Clemens Hintze <c.hintze@...> 1999/07/09

On Fri, 09 Jul 1999, you wrote:

[#443] — Michael Hohn <hohn@...>

Hello,

26 messages 1999/07/09
[#444] interactive ruby, debugger — gotoken@... (GOTO Kentaro) 1999/07/09

Hi Michael,

[ruby-talk:00533] Re: Another way for this? And a new proposal!

From: matz@... (Yukihiro Matsumoto)
Date: 1999-07-26 01:22:14 UTC
List: ruby-talk #533
Hi,

In message "[ruby-talk:00532] Re: Another way for this? And a new proposal!"
    on 99/07/25, Clemens Hintze <c.hintze@gmx.net> writes:

|But it is interesting! In a argument list it would convert a block to
|a Proc instance, while during method invocation it converts a Proc
|instance into a block! Nice, really :-)

Since Proc objects are objectified blocks, it is good to have convert
them both way.

|BTW: I have silly used the term `block' for the `do ... end' and `{
|... }' constructs. What would be the right term in Ruby?

I too call them blocks.  Formerly I used to call them iterator blocks,
but I removed the word 'iterator' because block is not only used for
iteration.   But you can call them iterator blocks still, to avoid
ambiguousness.

|Unfortunately not. Please have a look to my method `block' again. If I
|would use `lambda' or family, it would be an error to NOT providing
|`each' with a block or a Proc instance.
|
|What I would like to have, perhaps, would be a kind of `lambda',
|`proc' or `Proc#new' which would return `nil' if there was no block
|instead of issuing an exception.

Hmm..

|>|	def each(aBlock=(begin lambda rescue nil end))
|>|	   @list1.each aBlock
|>|	   @list2.each aBlock
|>|	end

Well, it's ugly.

|That would be the solution. Well... almost. The only remaining thing,
|that disturbes me a little bit it, that I (the programer) have to
|know, whether that certain method would expect a block or a Proc
|instance!
|
|I.e. I would have to know, whether I have to call a method like:
|
|	anyObject.anyMethod &blk
|or
|	anyObject.anyMethod blk

Use former.  I think it's better way.  'def foo(block=lambda)' trick
is older than the block argument.

|It is really a pitty, that Proc instances are not blocks! As block
|seem to behave like Proc instance, is it not possible to clean-up
|that difference? As blocks are faster than Proc instances, I would
|propose, that `Proc#new' would create blocks instead of Proc
|instances. Would that be possible?

Blocks are not objects, so it's not possible to return blocks.  As I
said before, Proc instances are objectified block, just like Method
instances are objectified methods which themselves are not objects.

                                                matz.

In This Thread