[#27003] [Bug #2422] splat operator fails on array of 1 element — Raul Parolari <redmine@...>

Bug #2422: splat operator fails on array of 1 element

12 messages 2009/12/02

[#27025] [Backport #2431] StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n" — Hiroshi NAKAMURA <redmine@...>

Backport #2431: StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n"

8 messages 2009/12/04

[#27086] [Feature #2454] OpenSSL has no maintainer — Yui NARUSE <redmine@...>

Feature #2454: OpenSSL has no maintainer

16 messages 2009/12/07

[#27120] #to_enum ignores block? — Roger Pack <rogerdpack@...>

Is #to_enum ignoring its block expected?

11 messages 2009/12/09

[#27135] better GC? — Roger Pack <rogerdpack@...>

Could I put in a small plea for a better GC?

56 messages 2009/12/10
[#27136] Re: better GC? — Yukihiro Matsumoto <matz@...> 2009/12/11

Hi,

[#27476] Re: better GC? — Paul Brannan <pbrannan@...> 2010/01/07

On Fri, Dec 11, 2009 at 09:07:16AM +0900, Yukihiro Matsumoto wrote:

[#27477] Re: better GC? — Eero Saynatkari <ruby-ml@...> 2010/01/07

Excerpts from Paul Brannan's message of Thu Jan 07 21:53:34 +0200 2010:

[#27563] Re: better GC? — Brent Roman <brent@...> 2010/01/12

[#27199] [Backport #2488] thread usage can result in bad HANDLE — Roger Pack <redmine@...>

Backport #2488: thread usage can result in bad HANDLE

12 messages 2009/12/16

[#27286] [Bug #2515] Array#select! — Roger Pack <redmine@...>

Bug #2515: Array#select!

17 messages 2009/12/22

[#27327] [Bug #2531] Ruby 1.8.7-p248 fails to cross-compile same version — Luis Lavena <redmine@...>

Bug #2531: Ruby 1.8.7-p248 fails to cross-compile same version

9 messages 2009/12/25

[#27360] [Feature #2542] URI lib should be updated to RFC 39886 — Marc-Andre Lafortune <redmine@...>

Feature #2542: URI lib should be updated to RFC 39886

15 messages 2009/12/31

[ruby-core:27141] Re: #to_enum ignores block?

From: Yusuke ENDOH <mame@...>
Date: 2009-12-11 09:58:04 UTC
List: ruby-core #27141
2009/12/11 Roger Pack <rogerdpack@gmail.com>:
>> http://mamememo.blogspot.com/2009/11/enumerablerrb-enumerable-lazy-version.html
>> http://d.hatena.ne.jp/ku-ma-me/20091111/p2 (in Japanese)
>
> Excellent.  I was wondering where those lazy versions of select were...
> As a note, though--I think it does use fibers if you do a #next call on one...

Yes.  It does not use fiber unless you do a #next call.


>> Matz said that these methods are acceptable to be embedded into the
>> core, but did not accept their names (selector, mapper, etc.).
>> Instead, Matz suggested enum_select, enum_map, etc., but I dislike
>> them because they are too verbose.
>
> perhaps select_enum?

`_enum', five letters are too verbose and uncool X-(


> I think we should keep both, since it's such a slowdown (and having to
> call #to_a everywhere might be a drag...) :)

`.to_a', just five letters :-)

`selector' is more important than `select' because selector can serve
as select but NOT vice vista.  So name length of selector should be
shorter (or almost same) than select.

Indeed, it needs some optimizations.  For example, if an enumerator
generated by selector is converted to array, it just evaluate the same
implementation of current select (only when the original array is not
modified after the enumerator is generated).

I'm not against "keep both."  But if we do so, we should need better
naming convension because there are many methods that return an array
and that will have *_enum methods respectively.

-- 
Yusuke ENDOH <mame@tsg.ne.jp>

In This Thread

Prev Next