Duplicate methods removal in Ruby's TODO ?

[David Unric]

Hi,

as you know for sure, Ruby defines several method aliases of base
classes to appeal/(make it easier to grasp) programmers comming from
different languages (Perl, Smalltalk, Lisp etc.).

Array:
'slice' and '[]'
'collect' and 'map'
'inspect' and 'to_s'

Enumerable:
'find_all' and 'select'
'find' and 'detect'
'entries' and 'to_a'
'inject' and 'reduce'
'include?' and 'member?'

Hash:
'store' and '[]'
'each' and 'each_pair'
'key?' and 'has_key?'
'value?' and 'has_value?'
'length' and 'size'
'merge' and 'update'

...

Just curious about possible removal of method aliases in a future ? I
know it would be very difficult decision to break backward
compatibility, but because these are synonyms/aliases it won't be too
hard to write conversion tool for existing sources.

Is there same intention to clean Ruby's core libraries ?
When'll be the time, Ruby would need no more to attract programmers from
different envirnoments and start with cleaning out ?

Take care


David

 

[Joey Zhou]

I just think some methods should add a trailing exclamation mark, which
are:

String#clear
String#concat
String#insert
String#replace
String#setbyte
Array#clear
Array#concat
Array#delete
Array#delete_at
Array#delete_if
Array#fill
Array#insert
Array#pop
Array#push
Array#replace
Array#shift
Array#unshift
Hash#clear
Hash#delete
Hash#delete_if
Hash#replace
Hash#shift
Hash#store
Hash#update (synonym for Hash#merge!, which has a bang!)

These methods all alert the receiver in place. They have no trailing
exclamation mark because there are no methods of the same name which
return a modified copy of the object only. I don't think a bang is an
alarm to tell you "there is a same name method", a bang should be an
alam "it will change your object, be carefull!" So string.clear should
be string.clear!, even if there's no "clear" method which doesn't alert
the receiver. I think it's logical.

 

[Shadowfirebird]

Excerpts from David Unric's message of Tue Mar 08 12:30:06 +0000 2011:

Hi,

as you know for sure, Ruby defines several method aliases of base
classes to appeal/(make it easier to grasp) programmers comming from
different languages (Perl, Smalltalk, Lisp etc.).

Array:
'slice' and '[]'
'collect' and 'map'
'inspect' and 'to_s'

Enumerable:
'find_all' and 'select'
'find' and 'detect'
'entries' and 'to_a'
'inject' and 'reduce'
'include?' and 'member?'

Hash:
'store' and '[]'
'each' and 'each_pair'
'key?' and 'has_key?'
'value?' and 'has_value?'
'length' and 'size'
'merge' and 'update'

...

Just curious about possible removal of method aliases in a future ? I
know it would be very difficult decision to break backward
compatibility, but because these are synonyms/aliases it won't be too
hard to write conversion tool for existing sources.

Is there same intention to clean Ruby's core libraries ?
When'll be the time, Ruby would need no more to attract programmers from
different envirnoments and start with cleaning out ?

Good gods, I hope not. Where would the advantage be, if these methods are just aliases for each other? And think of the number of programmers you would alienate!

 

[Shadowfirebird]

These methods all alert the receiver in place. They have no trailing

exclamation mark because there are no methods of the same name which
return a modified copy of the object only. I don't think a bang is an
alarm to tell you "there is a same name method", a bang should be an
alam "it will change your object, be carefull!" So string.clear should
be string.clear!, even if there's no "clear" method which doesn't alert
the receiver. I think it's logical.

This bugs me, too.

 

[Robert Klemme]

Hi,

as you know for sure, Ruby defines several method aliases of base
classes to appeal/(make it easier to grasp) programmers comming from
different languages (Perl, Smalltalk, Lisp etc.).

Array:
=A0'slice' and '[]'
=A0'collect' and 'map'
=A0'inspect' and 'to_s'

These are not exchangeable.

Enumerable:
=A0'find_all' and 'select'
=A0'find' and 'detect'
=A0'entries' and 'to_a'
=A0'inject' and 'reduce'
=A0'include?' and 'member?'

Hash:
=A0'store' and '[]'
=A0'each' and 'each_pair'
=A0'key?' and 'has_key?'
=A0'value?' and 'has_value?'
=A0'length' and 'size'
=A0'merge' and 'update'

...

Just curious about possible removal of method aliases in a future ? I
know it would be very difficult decision to break backward
compatibility, but because these are synonyms/aliases it won't be too
hard to write conversion tool for existing sources.

Why bother? This generates superfluous efforts because you gain
nothing other than some abstract "cleanness" or removal of redundancy.

Is there same intention to clean Ruby's core libraries ?
When'll be the time, Ruby would need no more to attract programmers from
different envirnoments and start with cleaning out ?

I don't think there are any such intentions. I'd strongly object to
them if there were. This just does not give any benefit and there
would be far better candidates for cleaning up (class variables should
be banned for example).

Cheers

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[David Unric]

Robert Klemme wrote in post #986190:

Why bother? This generates superfluous efforts because you gain
nothing other than some abstract "cleanness" or removal of redundancy.


I don't think there are any such intentions. I'd strongly object to
them if there were. This just does not give any benefit and there
would be far better candidates for cleaning up (class variables should
be banned for example).

Cheers
ne
robert

I'd guess reasons are obvious. You have to remember not only method
names but also their aliases you personally do not use just for the
sake of understanding other's source code. It does make you not a bit
more
productive. I'd prefer to spare my memory for much more important and
useful things.

If you'll have to analyze thousands of lines of code even with
inconsistent mix-up of both method aliases, your oppinion would
certainly change.

 

[Adam Prescott]

[Note: parts of this message were removed to make it a legal post.]

These methods all alert the receiver in place. They have no trailing
exclamation mark because there are no methods of the same name which
return a modified copy of the object only. I don't think a bang is an
alarm to tell you "there is a same name method", a bang should be an
alam "it will change your object, be carefull!" So string.clear should
be string.clear!, even if there's no "clear" method which doesn't alert
the receiver. I think it's logical.

Using bang names to denote receiver-modifying methods is not the convention,
and I don't think it should become it.

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

Using bang names to denote receiver-modifying methods is not the
convention,
and I don't think it should become it.

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

I think it should become the convention. I consider the bang to be nearly
meaningless as is.

 

[Robert Klemme]

Robert Klemme wrote in post #986190:

I'd guess reasons are obvious. You have to remember not only method
names but also their aliases you personally do not use just for the
sake of understanding other's source code. It does make you not a bit
more
productive. I'd prefer to spare my memory for much more important and
useful things.

If your memory gets low you can always swap that page out and reload it
from "ri".

If you'll have to analyze thousands of lines of code even with
inconsistent mix-up of both method aliases, your oppinion would
certainly change.

That does not match my experience. Usually code from the same author is
consistent. If of course you are dealing with classes which have
multiple authors then that might explain the mixup. Even then I don't
find it particular difficult to recognize methods that I usually not use
(#collect for example).

Even if it's different for you I do not find that your particular
hardship justifies creating work for all others who would have to adjust
their library code plus change their habits. The first thing that would
happen anyway is that someone publishes a gem with introduces all those
methods again - and people write their code as before.

Why do people so often put so much energy into trying to convince other
people that the language or the core library needs to be changed -
instead of just accepting things as they are and going with the flow?
This is suggestion of yours is a typical case where it is immediately
obvious that it has little chance of ever being realized - so why try to
push it?

Kind regards

robert

 

[Shadowfirebird]

Using bang names to denote receiver-modifying methods is not the convention,

and I don't think it should become it.

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

As the article you link to says: the convention is neither intuitive nor easy to understand.

+1 here for adopting a clearer convention.

 

[Shadowfirebird]

I'd guess reasons are obvious. You have to remember not only method

names but also their aliases you personally do not use just for the
sake of understanding other's source code. It does make you not a bit
more
productive. I'd prefer to spare my memory for much more important and
useful things.

Which would, I admit, be a fine argument. If it were not for the fact that ruby method names are all so damn intuitive. I for one don't have to remember anything; the names tell me roughly what the method does. And there is always ri to remind me of any details.

 

[Rob Biedenharn]

Which would, I admit, be a fine argument. If it were not for the
fact that ruby method names are all so damn intuitive. I for one
don't have to remember anything; the names tell me roughly what the
method does. And there is always ri to remind me of any details.

This is why I personally do not use Hash#merge! and prefer Hash#update
even though the former seems more common in the code that I read. I'd
rather the presence of '!' be a shorthand for "Hey, I hope you're
using me on purpose!"

-Rob

Rob Biedenharn
(e-mail address removed) http://AgileConsultingLLC.com/
(e-mail address removed) http://GaslightSoftware.com/

 

[Klaus Stein]

[ ! should mark methods changing the receiver ]

I think it should become the convention. I consider the bang to be nearly
meaningless as is.

It is _normal_ in OO that objects change state, contrary to functional
languages. In functional languages any functions with side-effects are
considered harmful (including print and puts).
In OO languages changing the state of an object is common:

a.name = "Peter" # oh, this changes a, name= should end with !

data << item # hm, data is changed, << should really have a !

e = mycoll.each # lets get an enumerator
first = e.next # this changes e, so should this be e.next! ?
# note: e is changed, mycoll is not

f = File.open("data") # open a file for reading
f.read(100) # hm, this changes f, should this be f.read! ?
# note: f is changed, the file "data" is not.

class A
attr_reader :x # hm, attr_reader changes A, should have a !
end

Prawn:ocument.generate('hello.pdf') do |pdf|
pdf.text("Hello Prawn!") # this changes pdf
pdf.canvas do
pdf.line pdf.bounds.bottom_left, pdf.bounds.top_right # this too!
end
end

and so on.

Klaus

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

[ ! should mark methods changing the receiver ]

I think it should become the convention. I consider the bang to be nearly
meaningless as is.

It is _normal_ in OO that objects change state, contrary to functional
languages. In functional languages any functions with side-effects are
considered harmful (including print and puts).
In OO languages changing the state of an object is common:

My point is not that OO languages are immutable, it is that bang methods are
nearly meaningless. They are too contextual and require too many rules and
exceptions to figure out, they also frequently return nil for no reason that
is apparent to me.

 

[Robert Klemme]

[ ! should mark methods changing the receiver ]

I think it should become the convention. I consider the bang to be nearly
meaningless as is.

It is _normal_ in OO that objects change state, contrary to functional
languages. In functional languages any functions with side-effects are
considered harmful (including print and puts).
In OO languages changing the state of an object is common:

My point is not that OO languages are immutable, it is that bang methods are
nearly meaningless. They are too contextual and require too many rules and
exceptions to figure out,

Hmm, I don't find it hard to be remembered that x.gsub! actually
changes x while x.gsub doesn't.

they also frequently return nil for no reason that
is apparent to me.

Frankly, I cannot remember having used fact (change of the receiver)
indicated by the return value. For my usage it would be more
convenient if I could do

File.foreach do |line|
line.chomp!.scan /.../ do
...
end
end

Who would wand to do this?

File.foreach do |line|
line.chomp! or warn "Found a line without terminator!"
...
end
end

Since terminators are used to separate lines only the last line might
be without trailing line terminator anyway.

I assume, it was originally thought that the information about a
change of an object in place was somehow useful. I guess only Matz or
whoever designed this can shed light on this design decision.

Kind regards

robert