[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5736] Re: Array#insert

From: matz@... (Yukihiro Matsumoto)
Date: 2000-10-21 15:32:38 UTC
List: ruby-talk #5736
Hi,

In message "[ruby-talk:5716] Re: Array#insert"
    on 00/10/21, Aleksi Niemel<aleksi.niemela@cinnober.com> writes:

|I think I'm following matz ideas when I named it to be "insert" instead of
|"insert!". And the reasoning is that currently the methods are not named
|with exclamation mark (!) if 
|
|1) the name clearly indicates the receiving object is going to change and/or
|2) there's no corresponding method with implicit dup. 
|
|In this case the name indicates the receiver is going to be changed, and
|there's no !-version (just like Array#delete_at doesn't have exclamation
|mark).
|
|My understanding is that a method which changes receiver can be named
|without !. But a method which does not change receiver can't be named with
|!.
|Also a method which has a non-receiver-mutating version too has to be named
|with !.
|
|I'm sure matz will correct me here, if I'm mistaken or the "rules" are
|incorrect. I'm also willing to create insert *and* insert! if it's thought
|to be necessary or the current way confusing. I don't feel so (yet :).

You're right.  Did you scan my brain lately?

And:

In message "[ruby-talk:5721] Re: Array#insert"
    on 00/10/21, Mark Slagell <ms@iastate.edu> writes:

|This is in fact one of the first things that startled me when learning
|about ruby. I'll give three reasons for wishing we were consistent about
|!/? naming:
|
|A. Least Surprise is not well served by the inconsistency, IMO. I'd love
|to be able to reliably know, when seeing the name of an unfamilar
|method, whether it is can be trusted not to change the receiver.
|
|B. Getting used to having garbage collection has made me more
|comfortable with programming in a functional style, as it's easier to
|reason about the behavior of non-destructive methods. So it is a nice
|convenience for me when destructive methods routinely turn out to have
|non-destructive equivalents. I guess what I'm saying is that "clearly
|indicates" is anything but clear much of the time, and is open to honest
|disagreement based on differing styles; for instance, you might not see
|a use for a non-destructive array insert whereas to me it might sound
|just as natural and sensible as non-destructive string concatenation.
|
|C. (related to B, but this applies even if you don't consistently prefer
|functional style) Naming a destructive method without the ! ties our
|hands - what can we do if we later change our mind later about the need
|for a non-destructive equivalent?

Well, your resolution is consistent and simpler, but it makes Ruby
programs full of bang signs, that makes programmers (at least me)
unhappy.  Although current rule is more complex than you expect, but
most human brain can handle it easily; I'm sure.

							matz.

In This Thread