[#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,
[#427] Re: New feature for Ruby?
— Clemens Hintze <c.hintze@...>
1999/07/02
On Fri, 02 Jul 1999, you wrote:
[#428] Re: New feature for Ruby?
— gotoken@... (GOTO Kentaro)
1999/07/03
Hi,
[#429] Re: New feature for Ruby?
— Clemens Hintze <c.hintze@...>
1999/07/03
On Sat, 03 Jul 1999, you wrote:
[#430] Re: New feature for Ruby?
— gotoken@... (GOTO Kentaro)
1999/07/05
Hi,
[#431] Re: New feature for Ruby?
— Clemens Hintze <c.hintze@...>
1999/07/07
On Mon, 05 Jul 1999, you wrote:
[#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:
[#452] Re: Now another totally different ;-)
— gotoken@... (GOTO Kentaro)
1999/07/11
Hi,
[#462] Re: Now another totally different ;-)
— matz@... (Yukihiro Matsumoto)
1999/07/12
Hello, there.
[#464] Re: Now another totally different ;-)
— Clemens Hintze <c.hintze@...>
1999/07/12
On Mon, 12 Jul 1999, you wrote:
[#467] Re: Now another totally different ;-)
— matz@... (Yukihiro Matsumoto)
1999/07/12
Hi,
[#468] Re: Now another totally different ;-)
— gotoken@... (GOTO Kentaro)
1999/07/12
In message "[ruby-talk:00467] Re: Now another totally different ;-)"
[#443] — Michael Hohn <hohn@...>
Hello,
26 messages
1999/07/09
[#444] interactive ruby, debugger
— gotoken@... (GOTO Kentaro)
1999/07/09
Hi Michael,
[#448] Re: interactive ruby, debugger
— "NAKAMURA, Hiroshi" <nakahiro@...>
1999/07/10
Hi,
[#450] Re: interactive ruby, debugger
— Clemens Hintze <c.hintze@...>
1999/07/10
On Sat, 10 Jul 1999, you wrote:
[#490] Some questions concerning GC in Ruby extensions — Clemens Hintze <c.hintze@...>
Hi matz,
6 messages
1999/07/14
[#501] Ruby 1.3.5 — Yukihiro Matsumoto <matz@...>
Ruby 1.3.5 is out, check out:
1 message
1999/07/15
[#519] CGI.rb — "Michael Neumann" <neumann@...>
Hi...
7 messages
1999/07/24
[#526] Another way for this? And a new proposal! — Clemens Hintze <c.hintze@...>
Hi,
6 messages
1999/07/25
[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.