[#27380] [Bug #2553] Fix pthreads slowness by eliminating unnecessary sigprocmask calls — Dan Peterson <redmine@...>

Bug #2553: Fix pthreads slowness by eliminating unnecessary sigprocmask calls

21 messages 2010/01/03

[#27437] [Feature #2561] 1.8.7 Patch reduces time cost of Rational operations by 50%. — Kurt Stephens <redmine@...>

Feature #2561: 1.8.7 Patch reduces time cost of Rational operations by 50%.

9 messages 2010/01/06

[#27447] [Bug #2564] [patch] re-initialize timer_thread_{lock,cond} after fork — Aliaksey Kandratsenka <redmine@...>

Bug #2564: [patch] re-initialize timer_thread_{lock,cond} after fork

18 messages 2010/01/06

[#27545] [Feature #2594] 1.8.7 Patch: Reduce time spent in gc.c is_pointer_to_heap(). — Kurt Stephens <redmine@...>

Feature #2594: 1.8.7 Patch: Reduce time spent in gc.c is_pointer_to_heap().

8 messages 2010/01/11

[#27635] [Bug #2619] Proposed method: Process.fork_supported? — Hongli Lai <redmine@...>

Bug #2619: Proposed method: Process.fork_supported?

45 messages 2010/01/20
[#27643] [Feature #2619] Proposed method: Process.fork_supported? — Luis Lavena <redmine@...> 2010/01/21

Issue #2619 has been updated by Luis Lavena.

[#27678] Re: [Feature #2619] Proposed method: Process.fork_supported? — Yukihiro Matsumoto <matz@...> 2010/01/22

Hi,

[#27684] Re: [Feature #2619] Proposed method: Process.fork_supported? — Charles Oliver Nutter <headius@...> 2010/01/22

On Thu, Jan 21, 2010 at 11:27 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#27708] Re: [Feature #2619] Proposed method: Process.fork_supported? — Yukihiro Matsumoto <matz@...> 2010/01/22

Hi,

[#27646] Re: [Bug #2619] Proposed method: Process.fork_supported? — Tanaka Akira <akr@...> 2010/01/21

2010/1/21 Hongli Lai <redmine@ruby-lang.org>:

[#27652] Re: [Bug #2619] Proposed method: Process.fork_supported? — Hongli Lai <hongli@...99.net> 2010/01/21

On 1/21/10 5:20 AM, Tanaka Akira wrote:

[#27653] Re: [Bug #2619] Proposed method: Process.fork_supported? — Tanaka Akira <akr@...> 2010/01/21

2010/1/21 Hongli Lai <hongli@plan99.net>:

[#27662] Re: [Bug #2619] Proposed method: Process.fork_supported? — Vladimir Sizikov <vsizikov@...> 2010/01/21

On Thu, Jan 21, 2010 at 10:53 AM, Tanaka Akira <akr@fsij.org> wrote:

[#27698] [Bug #2629] ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time — Hongli Lai <redmine@...>

Bug #2629: ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time

8 messages 2010/01/22

[#27722] [Feature #2635] Unbundle rdoc — Yui NARUSE <redmine@...>

Feature #2635: Unbundle rdoc

14 messages 2010/01/23

[#27757] [Bug #2638] ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located. — Joel Soete <redmine@...>

Bug #2638: ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located.

10 messages 2010/01/24

[#27778] [Bug #2641] Seg fault running miniruby during ruby build on Haiku — Alexander von Gluck <redmine@...>

Bug #2641: Seg fault running miniruby during ruby build on Haiku

10 messages 2010/01/25

[#27791] [Bug #2644] memory over-allocation with regexp — Greg Hazel <redmine@...>

Bug #2644: memory over-allocation with regexp

12 messages 2010/01/25

[#27794] [Bug #2647] Lack of testing for String#split — Hugh Sasse <redmine@...>

Bug #2647: Lack of testing for String#split

14 messages 2010/01/25

[#27912] [Bug #2669] mkmf find_executable doesn't find .bat files — Roger Pack <redmine@...>

Bug #2669: mkmf find_executable doesn't find .bat files

11 messages 2010/01/27

[#27930] [Bug:trunk] some behavior changes of lib/csv.rb between 1.8 and 1.9 — Yusuke ENDOH <mame@...>

Hi jeg2, or anyone who knows the implementation of FasterCSV,

15 messages 2010/01/28
[#27931] Re: [Bug:trunk] some behavior changes of lib/csv.rb between 1.8 and 1.9 — James Edward Gray II <james@...> 2010/01/28

On Jan 28, 2010, at 10:51 AM, Yusuke ENDOH wrote:

[ruby-core:27411] Re: [Feature #1082] add Object#singleton_class method

From: James Edward Gray II <james@...>
Date: 2010-01-05 03:21:34 UTC
List: ruby-core #27411
On Jan 4, 2010, at 8:41 PM, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: [ruby-core:27407] Re: [Feature #1082] add Object#singleton_class 	method"
>    on Tue, 5 Jan 2010 11:26:41 +0900, Shugo Maeda <shugo@ruby-lang.org> writes:
> 
> |I prefer singleton_class than eigenclass.  I suppose that "singleton
> |class" is not so confusing with a class which implements the Singleton
> |pattern because the word singleton remind Ruby users of singleton
> |methods rather than the Singleton pattern.
> 
> Basically, I agree.

I know we worry a lot about people confusing the term, but I've just never met anyone who does.  In all my time in Ruby, I haven't run across one single person who said to me, "Oh, you mean it's the Singleton Pattern?"  Have others really seen more of this problem actually occurring?

Even with the double meaning, I really don't feel like this is one of the more confusing concepts in programming.  We have much worse.  I personally have far more trouble teaching what a Symbol is in my classes, for example.  :)  If someone really does confuse it, we'll explain it and send them on their way armed with better knowledge.  

Finally, the damage is already done.  For a long time, Ruby considered it a singleton class, for better or worse.  We have core methods named after it, but are told we can't add a method because of the name.  I think it's a little late for that now.  Besides, if we change it people will just have a new problem, "Oh, didn't that use to be called the singleton class?"

Those are my three reasons why I vote for singleton class.

Matz, I know your patience exceeds mine 1,000 fold.  That's one of your great strengths and why you are in charge.  I totally trust you too.  However, I don't think you're going to find the perfect name this time.  You've waited a long time and heard a lot of choices.  If nothing has won you over yet, maybe we should just go with an OK choice that we already have.  Surely, seeing:

  obj.bad_name_class

is preferable to:

  class << obj; self end

and we can do even better than that with singleton_class.  :)

James Edward Gray II


In This Thread