Re: String.ord

On 2/7/07, [e-mail] <[e-mail]> wrote:
> Hi --
>
> On Wed, 7 Feb 2007, Nikolai Weibull wrote:
>
> > On 2/6/07, [e-mail] <[e-mail]> wrote:
> >> Hi --
> >>
> >> On Tue, 6 Feb 2007, Nikolai Weibull wrote:
> >>
> >> > On 2/6/07, Yukihiro Matsumoto <[e-mail]> wrote:
> >> >
> >> >> Both having ordAt(index) or making String#ord to return codepoint of
> >> >> the first character are trivial.  We have to evaluate pros and cons
> >> >> first.
> >> >
> >> > Like the fact that #ordAt isn't a very Rubyish name.  I really
> >> > appreciate the fact that the core and standard libraries use very
> >> > consistent naming schemes, where most methods have only one word in
> >> > them, thus avoiding the whole
> >> >
> >> came-case-versus-internal-upcasing-versus-lowline-separating-naming-scheme
> >> > holy-war.
> >>
> >> There are quite a few multi-word methods (respond_to?, values_at,
> >> to_i, instance_methods, etc.), all with the underscore style.  I agree
> >> there's no "war" aspect to it, but there's definitely a traditional
> >> style.
> >
> > What I meant was that it seems that people have been clever enough to
> > avoid multi-word methods as far as possible, so that there really
> > never has to be a discussion about it.  I know that the naming
> > conventions are camel-case for constants and lowlines for everything
> > else, but I realized early while reading through the early
> > documentation that every method seemed to have a very good single-word
> > name.
>
> irb(main):006:0> Object.new.methods.size
> => 40
> irb(main):007:0> Object.new.methods.grep(/_/).size
> => 17
>
> I guess __send__ and __id__ shouldn't count :-)  It's still a large
> percentage, though.  I don't think anyone's ever tried to avoid
> multi_word methods, except maybe when they get too big (though that
> can be handy too, in cases like instance_variable_get where the
> bigness draws attention to the possible inelegance of using the
> method).

Well, here's a another way of calculating the percentage (and gives a
percentage one fourth of your 43%):

String.new.public_methods(false).size /
String.new.public_methods(false).grep(/_/).size [1]

which gives us 11%.  Anyway, my feeling has always been that Ruby has
managed to use far simpler names for methods than many other
languages, which I appreciate.

  nikolai

[1] Using #public_methods instead of #methods should defeat my
argument, but I don't care.  Perhaps in 1.9/2.0 we'll have something
like #methods(:ancestors, :scope)?