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/.
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/.
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!
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'
These are not exchangeable.
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.
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
···
On Tue, Mar 8, 2011 at 1:30 PM, David Unric <dunric29a@gmail.com> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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/\.
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
···
On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <yimutang@gmail.com> 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.
I think it should become the convention. I consider the bang to be nearly
meaningless as is.
···
On Tue, Mar 8, 2011 at 12:12 PM, Adam Prescott <mentionuse@gmail.com> wrote:
On Tue, Mar 8, 2011 at 1:12 PM, Joey Zhou <yimutang@gmail.com> 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
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
···
On 08.03.2011 18:14, David Unric wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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.
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
Rob@AgileConsultingLLC.com http://AgileConsultingLLC.com/
rab@GaslightSoftware.com http://GaslightSoftware.com/
···
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.
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
···
Josh Cheek <josh.cheek@gmail.com> wrote:
> [ ! should mark methods changing the receiver ]
I think it should become the convention. I consider the bang to be nearly
meaningless as is.
--
The Answer is 42. And I am the Answer. Now I am looking for the Question.
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.
···
On Thu, Mar 17, 2011 at 1:00 PM, Klaus Stein <usenet@istik.de> wrote:
Josh Cheek <josh.cheek@gmail.com> 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:
> > [ ! 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
···
On Thu, Mar 17, 2011 at 7:34 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
On Thu, Mar 17, 2011 at 1:00 PM, Klaus Stein <usenet@istik.de> wrote:
Josh Cheek <josh.cheek@gmail.com> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/