[ruby-talk:5611] Re: Regexp#matches

Hal stated:
> I do prefer "matches" to "match." 

Me too. As an initiator of this thread :).

> But if conflicts with a prior design decision, it's not worth 
> bothering with, especially since I can define
> "matches" myself anytime I want. Enough said. Let's talk 
> about programming again.

I'm sure we have talked enough about differences of natural languages and
programming languages, namely English and Ruby. To lead the discussion back
to programming and Ruby programming in particular I'd like to continue this
mostly nonsensical issue.

I'm not sure what do you mean when you guess whether "matches" conflicts
with a prior design.

My original idea popped up from confusion. I like to say Regexp#matches, but
it's not defined. I vaguely remembered "exist" has an alias of "exists"
somewhere, so I went on hunting for it.

There are, however, definitions like these in file.c:

    define_filetest_function("exist?", test_e, 1);
    define_filetest_function("exists?", test_e, 1); /* temporary */

So there's only one alias for exists? and even that is marked to be
temporary, 

Browsing sources raised few other issues. One is that there are very few
aliases defined with rb_define_alias:

  Array#size       -> length
  IO#to_i          -> fileno
  Kernel.equal?    -> ==
  Kernel.===       -> ==

All the other are defined like the above, directly pointing two names to one
C-function. So my question is, is there a reason to use one way or another,
or should direct definitions instead of rb_define_alias be favored. 

For me it seems that rb_define_alias is the right one to do the job, and be
more explicit, but in code it seems to be a minority.

The other thing is that current Ruby has quite many aliases. I thought not
to paste them here, but instead I present the incomplete list at the end of
the mail. Most of the aliases lessen the count of surprises in Ruby. It's a
very good thing!!

     *And there are no aliases for 3rd person form*. 

So the Ruby is systematic here, and that's good.

For me it's ok to have purely imperative or infinitive form of verb. At the
same time, it's great Ruby is extendable. So maybe it's time to start
develop English.rb.

Someone said using own twists does not make source code portable. That's
true. And that's the major reason not to use own libraries just for nothing.
This time we have luck. Standard Ruby already has a module English.rb. Now
we just have to make it up to date. 

I guess we could start by adding as many 3rd person forms as necessary, but
no more than that, as potentially we could halt someone's program. My
English is definitely not too good, and I'm going to use that as a lame
excuse not volunteering for the major job - finding and reporting candidate
entries for Englishization :). 

But I can volunteer to gather and commit proposed changed to English.rb. So
if you think this is right way to go, 

1) start finding places for aliases etc.
2) report them to me (privately)
3) I'll propose the gathered changes to the ruby-talk
4) I'll commit the changes which are approved

	- Aleksi


Ps. And now the (almost) oneliner to find aliases, which I split to several
rows for easier understanding, and cut&pasting:

ruby -ne'BEGIN { $h={}; }; 
if $_ =~ /^\s*(rb_)?define_.*?\((.+)\s*"(.+)"\s*,\s*(.+)\s*,/; 
  if $h.has_key? $4; $h[$4]<<$3; else; $h[$4]=[$<.file.path.dup, $3]; end; 
end; 
END { $h.find_all {|k,v| v.size>=3; }.sort {|a, b| a[1] <=> b[1] }.
each {|k,v| printf("%15s %30s: %s\n", v[0], k, v[1,100].join(", "));}; };' 

Call the previous with *.c and you'll get a nice output like following on
unix machine:

        array.c                   rb_ary_equal: ==, ===
        array.c                    rb_ary_aref: [], slice
        array.c            rb_ary_collect_bang: collect!, map!
        array.c                 rb_ary_indexes: indexes, indices
        array.c                    rb_ary_to_a: to_a, to_ary
       bignum.c                  rb_big_modulo: %, modulo
       bignum.c                      rb_big_eq: ==, ===, eql?
       ...