Duplicate methods removal in Ruby's TODO ?

D

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
 
J

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.
 
S

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!
 
S

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.
 
R

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/
 
D

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.
 
A

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
 
R

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
 
S

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.
 
R

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/
 
K

Klaus Stein

Josh Cheek said:
[ ! 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::Document.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
 
J

Josh Cheek

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

Josh Cheek said:
[ ! 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.
 
R

Robert Klemme

Josh Cheek said:
[ ! 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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top