From: Intransition Date: 2010-06-05T13:35:23+09:00 Subject: Re: method_defined? does what exactly? On Jun 4, 9:42 am, Robert Dober wrote: > I agree with you and I would like to add that #method returns all > kind of methods and there is no method #private_method. > Would be too nice to have > #method(s), #private_method(s), #public_method(s) and #protected_method(s) > shrug. > > Consistency does not seem to be important to most, I have made this > experience before, and that has to be accepted :( I think it is more than that. I don't see much evidence that there is a great deal of consideration going into these additions at all. I watched Dave Thomas's "Ruby Sucks" talk yesterday, and he tried to paint a rosy picture around the whole thing. I agree with him to the extent that its cool that ruby is so flexible, but when he mentioned how they just throw methods in there, "Is it useful? Well I used it once. Okay!" That just struck a bad nerve. I do not see a whole lot of rational for what is getting into the language. But it's also not just stuff getting thrown in there. It's clearly selective, but on some esoteric, perhaps nepotist, or maybe it's as simple as a C coders clique making all the choices --actually I do think that is part of the problem. The people who write Ruby are first and foremost C coders, not Ruby programmers. I think most of them use Ruby like others use Perl --as an admin and tools language; as opposed to an applications framework. Of course, I don't know the actual reasons, but clearly something must explain it --I could easily name a dozen widely used extensions off the top of my head that make most of 1.9.2's new methods look absolutely lonely. I think if there were a rational process of determining what would be best to add to the language, it would be a careful cross-comparison of the most popular gems out there today. Look at they have common, the methods, idioms and patterns. Then figure out the best way to support these things in Ruby proper to the benefit them all. trans.