[#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:00529] Re: Another way for this? And a new proposal!
From:
matz@... (Yukihiro Matsumoto)
Date:
1999-07-25 18:08:13 UTC
List:
ruby-talk #529
Hi,
In message "[ruby-talk:00526] Another way for this? And a new proposal!"
on 99/07/25, Clemens Hintze <c.hintze@gmx.net> writes:
|I don't know, why following is not possible directly:
|
| blk1 = { |e| p(e) }
|or
| blk1 = do |e| p(e) end
|
|perhaps difficult to parse, matz?
Yes. { |e| p(e) } is too close to hash to distinguish for parser.
|Okay we would have on check more, but we would have the
|advantage, that the method could get both, a Proc instance or a
|block for execution. So it would be possible to do both:
|
| :
| <xxx>.each{ |e| p e }
| :
|and
| :
| blk = proc{ |e| p e }
| :
| <xxx>.each blk
| :
|
|wouldn't that be nice? Or is there any problem with these, that I
|have not seen until yet?
You can always do
def each(blk=lambda)
...
end
to receive blocks as the normal argument. By this way, you can supply
the Proc as the argument to the method, which also works as iterator.
|Unfortunately the following seems not to be possible at the moment:
|
| :
| def block; (iterator?) ? proc : nil end
|
| def each(aBlock=block)
| @list1.each aBlock
| @list2.each aBlock
| end
| :
|
|The method `block' will not be executed in the context of `each'! Is
|that designed so?
That's desined so. Use lambda/proc/Proc.new instead. They work as
you want, I guess.
You can pass block as the special block argument like:
blk = proc{ |e| p e }
<xxx>.each(&blk)
BTW, by historical reason, the block treatment is tuned up for yield.
The method using yield runs several times faster than one using Proc
object. That's one of the reasons why we can't avoid yield fully.
|Let me stress it once more: We would not only be able to iterate
|using a block, but also using a Proc instance. IMO, it would make
|Ruby more flexible. Furthermore it would bring block and Proc
|instances more close to each other.
|
|What do you think about?
I think the block argument &block (in invoking method) is the right
tool for you. You can pass any Proc object as the block.
binary_handler = proc{ <...> }
text_handler = proc{ <...> }
:
handler = textfile(filename) ? text_handler : binary_handler
File::open filename, &handler
matz.