Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Duplicate methods removal in Ruby's TODO ?

Reply
Thread Tools

Duplicate methods removal in Ruby's TODO ?

 
 
David Unric
Guest
Posts: n/a
 
      03-08-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 ?

Take care


David

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

 
Reply With Quote
 
 
 
 
Joey Zhou
Guest
Posts: n/a
 
      03-08-2011
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.

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

 
Reply With Quote
 
 
 
 
Shadowfirebird
Guest
Posts: n/a
 
      03-08-2011
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!

 
Reply With Quote
 
Shadowfirebird
Guest
Posts: n/a
 
      03-08-2011
> 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.

--
Never worry about theory as long as the machinery does what it's supposed to do.
-- R. A. Heinlein

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      03-08-2011
On Tue, Mar 8, 2011 at 1:30 PM, David Unric <(E-Mail Removed)> wrote:
> 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/

 
Reply With Quote
 
David Unric
Guest
Posts: n/a
 
      03-08-2011
Robert Klemme wrote in post #986190:
>> ...
>>
>> 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
> 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.

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

 
Reply With Quote
 
Adam Prescott
Guest
Posts: n/a
 
      03-08-2011
[Note: parts of this message were removed to make it a legal post.]

On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <(E-Mail Removed)> wrote:

> 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/...r-will-rubyist

 
Reply With Quote
 
Josh Cheek
Guest
Posts: n/a
 
      03-08-2011
[Note: parts of this message were removed to make it a legal post.]

On Tue, Mar 8, 2011 at 12:12 PM, Adam Prescott <(E-Mail Removed)> wrote:

> On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <(E-Mail Removed)> wrote:
>
> > 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/...r-will-rubyist
>


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

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      03-08-2011
On 08.03.2011 18:14, David Unric wrote:
> Robert Klemme wrote in post #986190:
>>> ...
>>>
>>> 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).

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

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Shadowfirebird
Guest
Posts: n/a
 
      03-08-2011
> 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/...r-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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
duplicate file removal tools? the_niner_nation Computer Support 12 11-30-2010 04:38 PM
Is there a way to find the class methods of a class, just like'methods' finds the instance methods? Kenneth McDonald Ruby 5 09-26-2008 03:09 PM
Gridview Duplicate removal. ASP .Net 12 02-15-2006 03:51 AM
Duplicate removal raja C Programming 5 02-07-2006 09:54 AM
Duplicate bookmark removal in firefox tmt Firefox 2 05-12-2005 02:46 PM



Advertisments