[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

Re: String.ord

From: dblack@...
Date: 2007-02-07 00:39:39 UTC
List: ruby-core #10217
Hi --

On Wed, 7 Feb 2007, Nikolai Weibull wrote:

> On 2/6/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>> 
>> On Tue, 6 Feb 2007, Nikolai Weibull wrote:
>> 
>> > On 2/6/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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).


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

In This Thread