[#20675] RCR: non-bang equivalent to []= — Tobias Reif <tobiasreif@...>

Hi,

49 messages 2001/09/01
[#20774] Re: RCR: non-bang equivalent to []= — Tobias Reif <tobiasreif@...> 2001/09/03

I wrote:

[#20778] Re: RCR: non-bang equivalent to []= — Kevin Smith <kevinbsmith@...> 2001/09/03

--- Tobias Reif <tobiasreif@pinkjuice.com> wrote:

[#20715] oreilly buch von matz - website online — markus jais <info@...>

hi

43 messages 2001/09/02
[#20717] Re: OReilly Ruby book has snail on cover — ptkwt@...1.aracnet.com (Phil Tomson) 2001/09/02

Actually, thanks for posting it here. I was trying to search OReilly's

[#20922] Re: OReilly Ruby book has snail on cover — Paul Brannan <pbrannan@...> 2001/09/05

On Mon, 3 Sep 2001, Phil Tomson wrote:

[#20768] Minor cgi.rb question — "Hal E. Fulton" <hal9000@...>

I don't have much experience with

25 messages 2001/09/03

[#20770] Calling member methods from C++ — jglueck@... (Bernhard Glk)

Some quetsions have been solved for me, but my message system does not

12 messages 2001/09/03

[#20976] destructor — Frank Sonnemans <ruby@...>

Does Ruby have a destructor as in C++?

25 messages 2001/09/07

[#21218] Ruby objects <-> XML: anyone working on this? — senderista@... (Tobin Baker)

Are there any Ruby analogs of these two Python modules (xml_pickle,

13 messages 2001/09/15

[#21296] nested require files need path internally — Bob Gustafson <bobgus@...>

Version: 1.64

29 messages 2001/09/18
[#21298] Re: nested require files need path internally — David Alan Black <dblack@...> 2001/09/18

Hello --

[#21302] Re: nested require files need path internally — Bob Gustafson <bobgus@...> 2001/09/18

On Tue, 18 Sep 2001, David Alan Black wrote:

[#21303] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21306] Re: nested require files need path internally — Lars Christensen <larsch@...> 2001/09/18

On Tue, 18 Sep 2001, Yukihiro Matsumoto wrote:

[#21307] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21331] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/18

> The big difference is C++ search done in compile time, Ruby search

[#21340] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21353] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/18

On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

[#21366] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/19

Hi,

[#21368] Re: nested require files need path internally — "Julian Fitzell" <julian-ml@...4.com> 2001/09/19

On 19/09/2001 at 10:12 AM matz@ruby-lang.org wrote:

[#21376] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/19

Hi,

[#21406] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/19

On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

[#21315] Suggestions for new CGI lib — anders@... (Anders Johannsen)

From the comp.lang.ruby thread "Minor cgi.rb question" (2001-09-03), I

21 messages 2001/09/18

[#21413] Ruby/objects book in style of The Little Lisper — Brian Marick <marick@...>

I fell in love with Lisp in the early 80's. Back then, I read a book called

36 messages 2001/09/19
[#21420] Re: Ruby/objects book in style of The Little Lisper — Christopher Sawtell <csawtell@...> 2001/09/20

On 20 Sep 2001 06:19:44 +0900, Brian Marick wrote:

[#21479] Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/21

--- Christopher Sawtell <csawtell@paradise.net.nz> wrote:

[#21491] SV: Re: Ruby/objects book in style of The Little Lisper — "Mikkel Damsgaard" <mikkel_damsgaard@...> 2001/09/21

[#21494] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/21

--- Mikkel Damsgaard <mikkel_damsgaard@mailme.dk> wrote:

[#21510] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Todd Gillespie <toddg@...> 2001/09/22

On Sat, 22 Sep 2001, Kevin Smith wrote:

[#21514] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/22

--- Todd Gillespie <toddg@mail.ma.utexas.edu> wrote:

[#21535] irb — Fabio <fabio.spelta@...>

Hello. :) I'm new here, and I have not found an archive of the previous

15 messages 2001/09/22

[#21616] opening a named pipe? — "Avdi B. Grimm" <avdi@...>

I'm having trouble reading from a named pipe in linux. basicly, I'm

12 messages 2001/09/24

[#21685] manipulating "immutable" objects such as Fixnum from within callbacks & al... — Guillaume Cottenceau <gc@...>

Hello,

15 messages 2001/09/25

[#21798] Ruby internal (guide to the source) — "Benoit Cerrina" <benoit.cerrina@...>

Hi,

22 messages 2001/09/28

[ruby-talk:20821] Re: RCR: non-bang equivalent to []=

From: Michael Neumann <neumann@...>
Date: 2001-09-03 22:48:20 UTC
List: ruby-talk #20821
Tobias Reif wrote:
> Matz,
> 
> 
> > |I'd like to have bang and non-bang versions of each and every method.
> > |The names should just differ in the !, like collect and collect!
> > 
> > Like scheme?  But imagine that every destructive (in other words, self
> > modifying) method has ! in its name, Ruby programs would be filled
> > with bangs.  It might be informative, but let's face it, it's ugly.
> 
> 
> By reading the docs, everyone can find out how each method acts.
> But a stringent concept would help programmers to always know how a 
> method behaves in this aspect; which would benefit the Princple of Least 
> Surprise.
> 
> If we were in the early phase (not having to consider finalized 
> decisions, and backwards-compatibility):
> 
> If destructive methods are more often used that non-destructive one, the 
> "default" (shorter name) could be destructive.
> Otherwise, the default is to be non-destructive, like now.
> 
> I agree that '!'s all over the place could be ugly.
> So maybe:
> All methods are destructive by default, and every method has a 
> counterpart which is non-destructive; since it returns a copy, _c could 
> be appended (exact naming convention is just a detail of a stringent 
> concept.).
> 
> Ruby is already at 1.7.x, so it's too late for all this.
> Or is it?
> Conventions for writing publicly available Ruby methods are interesting.
> And Ruby 2 too.
> 
> Here are more thoughts:
> 
> 
> I'm currently learning Ruby, and I like it a lot.
> 
> At first I thought that all methods return modified copies,
> and only "!" methods modify the original.
> 
> Then I ran into many problems, because []=
> is bang without having a "!" appended, and doesn't have
> a non-bang version.
> 
> AFAIK, there are many more methods that are destructive but don't
> declare that in their name:
> clear, delete, delete_at, delete_if, fill, pop, push, replace, shift,
> unshift, Array#filter.

"!" tells you "it's more dangerous to use it than the non-bang method". 
I don't thinks it's good to have for each method both, a destructive and 
non-destructive version. There is no Array#delete!, because it's obvious 
that delete is destructive; for the non-destructive version you might use 
Array#reject. 

> It would be OK if all methods are bang by default, and have some
> version which is non-bang.

I don't like that. How to name the non-bang methods?
Changing this would break all Ruby code out there.

> But I think any stringent concept and naming convention not only
> would immensely help beginners,
> but add to Ruby's semantic richness and clarity.
> Something like
> "Beware, however, that there are a fair number of destructive methods
> that don't have an '!' "
> in the FAQs it not a nice discovery for everyone learning Ruby.

Once again, "!" only marks a method as dangerous, that do not means, others
without it are less dangerous (destructive). 
For me it's obvious that

  a.delete_if {|i| i > 2}

would delete all elements larger than 2 from Array a. As mentioned above, I'd write

  b = a.reject {|i| i > 2}

for the non-destructive counterpart. 
For me, this is PoLS. 

If a method has a "!" version, you exactly know what each does. 
If there is no "!" version then take a look at the method name, if it sounds
destructive (delete, set []=, push, pop) then the method is destructive. 

> "The plain version takes a copy of the receiver, makes its change to it,
> and returns the copy. The version with the ! modifies the receiver in 
> place."
> is a rule with many non-obvious exceptions.
> This fact which generates confusion, and sabotages the
> "Princple of Least Surprise" in a very relevant way.
> 
> Any concept would solve the problem, as long as it's 100% stringent.

This would be the "Principle of No Surprise" but not PoLS ;-)

> (it could also be promoted as good style for all Ruby programs and libraries
> that make methods available. For example:
> Every method without a '!' makes a copy,
> every method with a '!' is destructive.
> Every method that is to be used by others
> (in public classes, libraries, etc.) should consist of both versions.)

There are many methods, that do not modify the object; should then for each method
a "!" version? There are two many methods, where this doesn't make any sense (most 
libraries other than datatypes).

  class Sensor

    def getTemparature
      @temperature 
    end

    def setTemparature(x)
      @temperature = x
    end

  end

Method "setTemperature" is destuctive, should it return a modified copy? 
Or would you call "setTemperature!" instead ?
Would you use Array#pop! instead of Array#pop?


> One possible concept:
> 
> (current, and stringent)
> 1. Variable assignment ist just that; nothing gets copied.
> 1.1. Use dup or clone to get a copy, and assign that.
> 
> (possible:)
> 2. Every method returns a (possibly modified) copy of what it
> worked with.
> 2.2. Every method has a version that doesn't make a copy,
> but directly works with the original.
> 
> Or:
> (possible:)
> 2. Every method works directly with the original.
> 2.2. If you don't want to modify the original,
> use dup or clone to get a copy and pass that.
> 
> Naming conventions like:
> map, copy_and_map
> or
> map_original, map
> or even
> map_original, copy_and_map
> are semantically rich, but too long.
> 
> So perhaps:
> 

map, map!


I am sure, the longer you work with Ruby the more you'll 
like the method names as they are.


Regards,

  Michael

-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de

In This Thread