[YANQ] -yet another (ruby) newbie question -string#concat

ruby-talk
1

Hi sir David (aka dblack@candle.superlink.net
[mailto:dblack@candle.superlink.net]):

You enlightened last Monday, December 09, 2002 12:04 PM:

Then #replace method is another thing I would avoid since the
syntax/nami=
ng
has implications or assumptions. Syntax/Naming should be unambiguous as
m=
uch
as possible, imho… Why can we not standardize on suffixing “!” on
metho=
ds
that modifies objects? Are they too many? Though, this is not a big
probl=
em
for me really, as of now, since I’m actually avoiding them… :slight_smile:

Hmmm… I wish I could figure out how to talk you out of that. I
think you’re investing the concept of object-modification with much
more complexity than it has.

I may change soon if I cannot live with it any longer :slight_smile: Remember, I am
just talking about the “!”-methods, and I think, they are not too many…

As for having all destructive/modifying methods use !: we’d end up
with an awful lot of !'s in our code :slight_smile:

a =3D [1,2,3,4]
a.push!(5) # and a.push(5) would create a dup of a???
a[-1]! =3D 6 # as in: a.=3D!(-1,6)
a.delete_if! {|x| x =3D=3D 3}

etc., etc…

They are indeed too many. And “!” makes method names ugly. So basically,
the question is how to recognize destructive methods (since I guess we
cannot live/trust with “!” alone).

There’s a lot of previous discussion on this (the general ! question,
not concat specifically). I searched for “destructive modify
receiver” on ruby-talk and hit a few such threads.

I would have prefered that there be NO destructive methods.
So using your examples above, I would rewrite them as:

a = [1,2,3,4]
a = a.push(5)
a = (a[-1] = 6) #errs since = does not return array
a = a.delete_if! {|x| x == 3}

and, I’m actually doing ruby coding like this now (pls don’t laugh :-):

a = [1,2,3,4]
b = a.dup #save a
a = a.push(5).delete_if{|x| x==2} # modify a anytime

p "a now is ",a
p "a originally was ",b

Imho, the = .method… is more explicit and therefore
less confusing. True, it needs more typing, but that is the price I have to
pay of being very explicit (and less questions for me).

Or maybe, how about a ruby directive/option that disables methods fr being
destructive (so that nubies like me would have a playing field)?

David

Kind regards,
-botp

2

As for having all destructive/modifying methods use !: we’d end up
with an awful lot of !'s in our code :slight_smile:

a =3D [1,2,3,4]
a.push!(5) # and a.push(5) would create a dup of a???
a[-1]! =3D 6 # as in: a.=3D!(-1,6)
a.delete_if! {|x| x =3D=3D 3}

etc., etc…

They are indeed too many. And “!” makes method names ugly. So basically,
the question is how to recognize destructive methods (since I guess we
cannot live/trust with “!” alone).

No, they are beautiful. Repeat after me: beautiful :wink:

There’s a lot of previous discussion on this (the general ! question,
not concat specifically). I searched for “destructive modify
receiver” on ruby-talk and hit a few such threads.

I would have prefered that there be NO destructive methods.
So using your examples above, I would rewrite them as:

a = [1,2,3,4]
a = a.push(5)
a = (a[-1] = 6) #errs since = does not return array
a = a.delete_if! {|x| x == 3}

and, I’m actually doing ruby coding like this now (pls don’t laugh :-):

I can’t help laughing, I’m afraid, but it’s with the greatest of affection for
yourself and all the useful questions you ask!

a = [1,2,3,4]
b = a.dup #save a
a = a.push(5).delete_if{|x| x==2} # modify a anytime

p "a now is ",a
p "a originally was ",b

Imho, the = .method… is more explicit and therefore
less confusing. True, it needs more typing, but that is the price I have to
pay of being very explicit (and less questions for me).

There’s nothing really confusing about objects being modified. All data can be
modified, so why not the data in objects? I think you need to treat your
symptoms like a fear of spiders: confront your fear, modify every object in
sight until you are used to it :wink: (just kidding, of course)

Or maybe, how about a ruby directive/option that disables methods fr being
destructive (so that nubies like me would have a playing field)?

Now that’s just being ridiculous! :smiley:

Anyway, you have two options at your disposal:

  • irb is an excellent playing field
  • freeze every object you create, then you can’t modifiy them!

Cheers,
Gavin

···

From: “Peña, Botp” botp@delmonte-phil.com

3

Hi –

I would have prefered that there be NO destructive methods.
So using your examples above, I would rewrite them as:

a = [1,2,3,4]
a = a.push(5)
a = (a[-1] = 6) #errs since = does not return array
a = a.delete_if! {|x| x == 3}

and, I’m actually doing ruby coding like this now (pls don’t laugh :-):

I won’t laugh, but I’ll offer my very strong advice not to tie
yourself in knots in order to get around the basic workings of data in
Ruby. Some day we’ll have to hypnotize you and see if we can find out
why this all bothers you so much :slight_smile: But meanwhile – it’s really
going to take a lot of your time, and make your code much less
effective (and readable, and probably usable), if you try to get Ruby
to masquerade as a language whose objects are immutable objects.

a = [1,2,3,4]
b = a.dup #save a
a = a.push(5).delete_if{|x| x==2} # modify a anytime

p "a now is ",a
p "a originally was ",b

Imho, the = .method… is more explicit and therefore
less confusing. True, it needs more typing, but that is the price I have to
pay of being very explicit (and less questions for me).

And it’s different. a = a.push(5) is not the same as a.push(5); it’s
not just a matter of how much you have to type. (See my earlier post
about S < String etc.)

Or maybe, how about a ruby directive/option that disables methods fr being
destructive (so that nubies like me would have a playing field)?

OK, can I laugh now? :slight_smile: Just kidding. But I think this is a
“singleton” problem of yours, not a general nuby thing. At least,
I’ve never heard it before.

Take heart! We will get you through this!

David

···

On Mon, 9 Dec 2002, [iso-8859-1] “Peña, Botp” wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

4

Mon, 9 Dec 2002 19:08:43 +0900, Gavin Sinclair gsinclair@soyabean.com.au pisze:

There’s nothing really confusing about objects being modified.
All data can be modified, so why not the data in objects? I think
you need to treat your symptoms like a fear of spiders: confront
your fear, modify every object in sight until you are used to it :wink:
(just kidding, of course)

Well, functional programming is a paradigm that avoids modifying
objects, and it produces readable and concise programs. There is
nothing strange in treating data as immutable :slight_smile:

You can program in more functional style in Ruby if you wish. It’s
great that it also provides those non-! methods. The style can be
mixed - some people prefer to modify more, some less.

Ruby doesn’t has that much library support for immutable data as
typical functional languages though - there are no Lisp-style lists
or functional dictionaries for example.

String is the primary type which usually makes sense to avoid
modifying, even if you can. You can create a new string locally in
a function and incrementally build it, but better avoid functions
which modify their arguments.

···

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.