Why are there so many similar/identical methods in core classes

Let’s look at the Array class and start with method aliases.

There are two aliases : .to_s <=> inspect , .size <=> .length , index
<=> find_index. I understand the need for the first one, since sometimes
the two don’t return the same thing depending on the class. But why have
size/length do the exact same thing…? This is one pretty intuitive so
it’s not that bad.h

Then we have methods that are defined together, but with different names
: collect <=> map , [] <=> slice <=> at.

Next we have methods that seem to be doing the same thing, but are
implemented differently : keep_if <=> select! , reject! <=> delete_if ,
delete_at <=> slice! <=> shift

Next are the nearly identical methods. They are the same except one does
a little : count <=> length/size

Useless methods? : replace. Why do you need an explicit method for this.
Can’t you just use the assignment operator ?

These are just the ones I remember/found. I’m sure there are many more
examples in this class and others. Doesn’t having multiple names for the
same thing make it confusing when collaborating ? Is there any reason
for this ? What is your take on the matter ?

It is to make Ruby a language that is more natural. As a dev, I love it
when things JUST_WORK and ruby does aliases to make that happen.

On Thu, Dec 1, 2011 at 10:15 PM, Kassym D. [email protected]
wrote:

These are just the ones I remember/found. I’m sure there are many more
examples in this class and others. Doesn’t having multiple names for the
same thing make it confusing when collaborating ? Is there any reason
for this ? What is your take on the matter ?


Posted via http://www.ruby-forum.com/.


Sincerely,

Isaac S.
Section C-4B Vice Chief, Order of the Arrow
Vice Chief of Administration, Tecumseh #65
Eagle Scout

On Thu, Dec 1, 2011 at 9:15 PM, Kassym D. [email protected]
wrote:

These are just the ones I remember/found. I’m sure there are many more
examples in this class and others. Doesn’t having multiple names for the
same thing make it confusing when collaborating ? Is there any reason
for this ? What is your take on the matter ?


Posted via http://www.ruby-forum.com/.

IDK for all of them. Some are actually different, to_s and inspect are
quite different (and brillaint!).

Others like map and collect are that way in order to appeal to different
audiences. I think map comes from Lisp and Collect comes from Smalltalk.
So
these are both common names for this method, and thus they are both
available. Same for size and length, and reduce and inject.

Others I think are synonyms either for convenience, or because they make
more sense in different contexts. I’d expect most of the operators are
defined for convenience (ie there is a method that does this, but b/c
Ruby
allows operator overloading, they realize the operator would make a lot
of
sense if it did this same thing, and are thus aliased).

Ruby generally adheres to TIMTOWDI, but I find I usually settle on a
preferred version, though it is sometimes fun to play with alternatives.

On Fri, Dec 2, 2011 at 4:15 AM, Kassym D. [email protected]
wrote:

Useless methods? : replace. Why do you need an explicit method for this.
Can’t you just use the assignment operator ?

No, you can’t.

irb(main):001:0> a = 5.times.to_a
=> [0, 1, 2, 3, 4]
irb(main):002:0> b = a
=> [0, 1, 2, 3, 4]
irb(main):003:0> a = %w{foo bar}
=> [“foo”, “bar”]
irb(main):004:0> b
=> [0, 1, 2, 3, 4]
irb(main):005:0> # BUT ---------------------------
irb(main):006:0* a = 5.times.to_a
=> [0, 1, 2, 3, 4]
irb(main):007:0> b = a
=> [0, 1, 2, 3, 4]
irb(main):008:0> a.replace %w{foo bar}
=> [“foo”, “bar”]
irb(main):009:0> a
=> [“foo”, “bar”]
irb(main):010:0> b
=> [“foo”, “bar”]
irb(main):011:0>

Kind regards

robert

These are just the ones I remember/found. I’m sure there are many
more examples in this class and others. Doesn’t having multiple names
for the same thing make it confusing when collaborating ? Is there
any reason for this ? What is your take on the matter ?

Of course there is a reason for it. It is called aliases.

You can use aliases in bash. I currently have almost 16.000 aliases.

Ruby is not a dictator enforcing a specific style per se. And I make
heavy use of aliases in Ruby code I write. Being able to use aliases
allows you to use several ways to call the same method too.

It helps when creating different DSLs too.

The language C uses aliases too. They are called “pointers” and
you can point to a pointer, to a function, or have functions call
or return pointers.

Aliases are everywhere.

Even if natural languages, you use aliases. It can be confusing
too. In german, if you say “Bank”, you either mean a bank where
you can put money into on an account, or you mean a bank which is
similar to a bench, where you can sit down. The context determines
which one is valid.

Would the world be better without aliases? Perhaps. But the
complexity still exists, as you need to use a new word. Natural
languages become more and more complicated, simply because there
are new words and new concepts needing new words.

As for collaborating with other people’s code, that is true, but
you can not blame aliases for that alone. They are very low on
my list.

What is higher on the list is the programming style of someone
else. Especially when a lot of eval* are used and a lot of
Proc.new - this all confuses me to no ends.

I sometimes wonder how a minimalistic ruby would look like (minimalistic
in syntax. If I’d ever make a programming language, I would make the
stdlib HUGE. When like 5 people need to use something, and code
something
on their own which has 95% overlapping functionality, I’d automatically
throw it into stdlib. Come to think about it, a programming language
designed and shared completely on git + github would be awesome. Sadly,
my C will forever more suck, so there is no point for me to try and
create my own language, even though I have some ideas that are not
existing in all the languages I know of.)

Ah. The reason why I wrote “minimalistic syntax” is because I do agree
that newcomers to Ruby often find parts of it too complicated.

Take Symbols vs. Strings. It is boring. Symbols are boring. Strings are
fun. Whoever recommends using Symbols is boring people.

Do newcomers really need to understand Symbols in order to use Ruby? I
would argue that it introduces a layer of complexity for hardly any real
gain in productivity when writing applications in Ruby.

And there are many more examples I’d change - the class vs. module
distinction, which I still don’t like. Class variables, while there are
a few valid use cases, I simply hate them.

On Sun, Dec 4, 2011 at 12:05 AM, Marc H. [email protected]
wrote:

You can use aliases in bash. I currently have almost 16.000 aliases.

O.o

Even if natural languages, you use aliases. It can be confusing
too. In german, if you say “Bank”, you either mean a bank where
you can put money into on an account, or you mean a bank which is
similar to a bench, where you can sit down. The context determines
which one is valid.

That’s not an alias, that’s a namespace. A real world example would be
like
color and colour.

When like 5 people need to use something, and code
something
on their own which has 95% overlapping functionality, I’d automatically
throw it into stdlib.

What’s wrong with gems?

Come to think about it, a programming language
designed and shared completely on git + github would be awesome.

Ruby source is on github (GitHub - ruby/ruby: The Ruby Programming Language) and almost all
gems’ source is on github.

On Sun, Dec 4, 2011 at 10:16, Josh C. [email protected] wrote:

Ruby source is on github (GitHub - ruby/ruby: The Ruby Programming Language) and almost all
gems’ source is on github.

Not to mention that development of stdlib will move to gems (
http://www.rubyinside.com/the-ruby-standard-library-to-be-converted-to-gems-for-ruby-2-0-5586.html
).

-Nick K.

On Sun, Dec 4, 2011 at 7:07 AM, Marc H. [email protected]
wrote:

Ah. The reason why I wrote “minimalistic syntax” is because I do agree
that newcomers to Ruby often find parts of it too complicated.

You are not talking about syntax: you are talking about interfaces of
classes or more generally about the interface of the standard library.
That’s a different thing.

Take Symbols vs. Strings. It is boring. Symbols are boring. Strings are
fun. Whoever recommends using Symbols is boring people.

I am sorry, I can’t take that serious. You must be joking.

Do newcomers really need to understand Symbols in order to use Ruby? I
would argue that it introduces a layer of complexity for hardly any real
gain in productivity when writing applications in Ruby.

Symbols are not primarily about gains in productivity - Symbols help
express particular semantics (fixed keys) and they have a smaller
memory footprint than Strings (at least when Strings are used as they
are often used, i.e. with a String literal in code like “foo”).

I am unsure though whether it is something a beginner needs to know.
But even if not, what would be the consequence? Do you want to create
a minimalistic Ruby for beginners to learn only to confront them later
with the real language so they realize they didn’t learn Ruby but just
ruby? What would be the benefit from that which could not be gained
by having a tutorial only using a particular subset of the language to
keep the learning scope small?

And there are many more examples I’d change - the class vs. module
distinction, which I still don’t like. Class variables, while there are
a few valid use cases, I simply hate them.

I agree with regard to class variables. I’d even say they might be
the biggest design flaw of the language.

If you find distinction between classes and modules superfluous it may
be an indication that you did not understand them properly.

Regards

robert

On Sun, Dec 4, 2011 at 7:05 AM, Marc H. [email protected]
wrote:

The language C uses aliases too. They are called “pointers” and
you can point to a pointer, to a function, or have functions call
or return pointers.

An alias is not the same as using a C pointer. A C pointer has one
more level of indirection which an alias does not have.

What is higher on the list is the programming style of someone
else. Especially when a lot of eval* are used and a lot of
Proc.new - this all confuses me to no ends.

It seems here we have the real motivation for this thread. But do you
think it is a good idea to make personal experience of one person the
guideline for language evolution?

I sometimes wonder how a minimalistic ruby would look like (minimalistic
in syntax. If I’d ever make a programming language, I would make the
stdlib HUGE. When like 5 people need to use something, and code
something
on their own which has 95% overlapping functionality, I’d automatically
throw it into stdlib.

I believe you should think a bit more about this idea of yours.
Especially please think about the downsides of this approach.

Kind regards

robert

Marc H. wrote in post #1034986:

Take Symbols vs. Strings. It is boring. Symbols are boring. Strings are
fun. Whoever recommends using Symbols is boring people.

i do not share your opinion.

i use smybols as keys in a hash and in multible other locations at the
same time, if i would use Strings instat the memory usage would be
multiplied with n

Hans M. wrote in post #1035077:

Marc H. wrote in post #1034986:

Take Symbols vs. Strings. It is boring. Symbols are boring. Strings are
fun. Whoever recommends using Symbols is boring people.

i do not share your opinion.

i use smybols as keys in a hash and in multible other locations at the
same time, if i would use Strings instat the memory usage would be
multiplied with n

Have you actually measured it, or are you just guessing?

Did you know that multiple String objects in ruby can share a reference
to the same underlying storage, with copy-on-write?

I’d say the guideline is: use the tool which makes your intention the
clearest, not the one which might (or might not) shave a half a
microsecond off the runtime. If that half-microsecond really mattered,
you wouldn’t be using ruby in the first place.

OTOH, I’d hardly describe strings as “fun” these days.

-----Messaggio originale-----
Da: Kassym D. [mailto:[email protected]]
Inviato: venerd 2 dicembre 2011 04:16
A: ruby-talk ML
Oggetto: Why are there so many similar/identical methods in core classes

Let’s look at the Array class and start with method aliases.

There are two aliases : .to_s <=> inspect , .size <=> .length , index
<=>
find_index. I understand the need for the first one, since sometimes the
two
don’t return the same thing depending on the class. But why have
size/length
do the exact same thing…? This is one pretty intuitive so it’s not that
bad.h

Then we have methods that are defined together, but with different names
: collect <=> map , [] <=> slice <=> at.

Next we have methods that seem to be doing the same thing, but are
implemented differently : keep_if <=> select! , reject! <=> delete_if ,
delete_at <=> slice! <=> shift

Next are the nearly identical methods. They are the same except one does
a
little : count <=> length/size

Useless methods? : replace. Why do you need an explicit method for this.
Can’t you just use the assignment operator ?

These are just the ones I remember/found. I’m sure there are many more
examples in this class and others. Doesn’t having multiple names for the
same thing make it confusing when collaborating ? Is there any reason
for
this ? What is your take on the matter ?


Posted via http://www.ruby-forum.com/.


Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Riccione Hotel 3 stelle in centro: Pacchetto Capodanno mezza pensione,
animazione bimbi, zona relax, parcheggio. Scopri l’offerta solo per
oggi…
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid982&d)-12

-----Messaggio originale-----
Da: Josh C. [mailto:[email protected]]
Inviato: venerd 2 dicembre 2011 05:06
A: ruby-talk ML
Oggetto: Re: Why are there so many similar/identical methods in core
classes

On Thu, Dec 1, 2011 at 9:15 PM, Kassym D. [email protected]
wrote:

: collect <=> map , [] <=> slice <=> at.

These are just the ones I remember/found. I’m sure there are many
more examples in this class and others. Doesn’t having multiple names
for the same thing make it confusing when collaborating ? Is there any
reason for this ? What is your take on the matter ?


Posted via http://www.ruby-forum.com/.

IDK for all of them. Some are actually different, to_s and inspect are
quite
different (and brillaint!).

Others like map and collect are that way in order to appeal to different
audiences. I think map comes from Lisp and Collect comes from Smalltalk.
So
these are both common names for this method, and thus they are both
available. Same for size and length, and reduce and inject.

Others I think are synonyms either for convenience, or because they make
more sense in different contexts. I’d expect most of the operators are
defined for convenience (ie there is a method that does this, but b/c
Ruby
allows operator overloading, they realize the operator would make a lot
of
sense if it did this same thing, and are thus aliased).

Ruby generally adheres to TIMTOWDI, but I find I usually settle on a
preferred version, though it is sometimes fun to play with alternatives.


Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
ING DIRECT Conto Arancio. 4,20% per 12 mesi, zero spese, aprilo in due
minuti!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid921&d)-12