Duplicate methods removal in Ruby's TODO ?

Discussion in 'Ruby' started by David Unric, Mar 8, 2011.

  1. David Unric

    David Unric Guest

    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/.
    David Unric, Mar 8, 2011
    #1
    1. Advertising

  2. David Unric

    Joey Zhou Guest

    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/.
    Joey Zhou, Mar 8, 2011
    #2
    1. Advertising

  3. 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, Mar 8, 2011
    #3
  4. > 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
    Shadowfirebird, Mar 8, 2011
    #4
  5. On Tue, Mar 8, 2011 at 1:30 PM, David Unric <> 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/
    Robert Klemme, Mar 8, 2011
    #5
  6. David Unric

    David Unric Guest

    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/.
    David Unric, Mar 8, 2011
    #6
  7. [Note: parts of this message were removed to make it a legal post.]

    On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <> 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/bang-methods-or-danger-will-rubyist
    Adam Prescott, Mar 8, 2011
    #7
  8. David Unric

    Josh Cheek Guest

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

    On Tue, Mar 8, 2011 at 12:12 PM, Adam Prescott <> wrote:

    > On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <> 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/bang-methods-or-danger-will-rubyist
    >


    I think it should become the convention. I consider the bang to be nearly
    meaningless as is.
    Josh Cheek, Mar 8, 2011
    #8
  9. 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/
    Robert Klemme, Mar 8, 2011
    #9
  10. Shadowfirebird, Mar 8, 2011
    #10
  11. > 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.
    Shadowfirebird, Mar 8, 2011
    #11
  12. On Mar 8, 2011, at 5:26 PM, Shadowfirebird wrote:

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



    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
    http://AgileConsultingLLC.com/
    http://GaslightSoftware.com/
    Rob Biedenharn, Mar 9, 2011
    #12
  13. David Unric

    Klaus Stein Guest

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

    --
    http://lapiz.istik.de/

    The Answer is 42. And I am the Answer. Now I am looking for the Question.
    Klaus Stein, Mar 17, 2011
    #13
  14. David Unric

    Josh Cheek Guest

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

    On Thu, Mar 17, 2011 at 1:00 PM, Klaus Stein <> wrote:

    > Josh Cheek <> wrote:
    > > > [ ! 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.
    Josh Cheek, Mar 17, 2011
    #14
  15. On Thu, Mar 17, 2011 at 7:34 PM, Josh Cheek <> wrote:
    > On Thu, Mar 17, 2011 at 1:00 PM, Klaus Stein <> wrote:
    >
    >> Josh Cheek <> wrote:
    >> > > [ ! 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


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Mar 18, 2011
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. S.M. Altaf [MVP]

    Re: Gracias por todo, me ha servido de ayuda V2DW

    S.M. Altaf [MVP], Oct 31, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    438
  2. Guest

    Gridview Duplicate removal.

    Guest, Feb 7, 2006, in forum: ASP .Net
    Replies:
    12
    Views:
    6,746
    Yuan Ren[MSFT]
    Feb 15, 2006
  3. Phillip Lord

    JUnit, writing todo tests...

    Phillip Lord, Feb 9, 2004, in forum: Java
    Replies:
    4
    Views:
    798
    Scott Ellsworth
    Feb 12, 2004
  4. lucy
    Replies:
    6
    Views:
    1,284
    Carl Howells
    Sep 2, 2004
  5. raja

    Duplicate removal

    raja, Feb 4, 2006, in forum: C Programming
    Replies:
    5
    Views:
    336
    Arndt Jonasson
    Feb 7, 2006
Loading...

Share This Page