[#18121] [Ruby 1.8.7 - Bug #405] (Open) ssl.rb:31: [BUG] Bus Error — Anonymous <redmine@...>

Issue #405 has been reported by Anonymous.

14 messages 2008/08/04

[#18130] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Brian Candler <B.Candler@...>

> Seriously though... Array.first is a noun.

10 messages 2008/08/05

[#18319] NEW Command: absolute_path() -- — "C.E. Thornton" <admin@...>

Core,

14 messages 2008/08/16
[#18321] Re: NEW Command: absolute_path() -- — Yukihiro Matsumoto <matz@...> 2008/08/18

Hi,

[#18381] [Bug #496] DRb.start_service(nil) is very slow — Hongli Lai <redmine@...>

Bug #496: DRb.start_service(nil) is very slow

11 messages 2008/08/25

[ruby-core:18200] Re: New array methods cycle, choice, shuffle (plus bug in cycle)

From: "David A. Black" <dblack@...>
Date: 2008-08-08 12:08:35 UTC
List: ruby-core #18200
Hi --

On Fri, 8 Aug 2008, gdefty@attglobal.net wrote:

> Hi,
>
> I think that the verb/noun difference IS at the
> heart of it. It seems that a bang version of a
> verb makes sense ('do something' vs 'do somthing
> to the receiver') where a bang version of a noun
> ('this thing') does not.

Exactly. I realize this all the more when I realize that this:

    array.take_sample!

would make sense to me as a "dangerous"/destructive method. Maybe
other's are sensing sample on its own as a verb. It comes across
noun-like to me.

> I also thought a lot about Matz's response:
>
> | Basic rule of bang methods for strings and
> arrays are modifying
> | receivers in-place instead of modifying the
> copies, i.e. Array#sort
> | returns an sorted (copied) array, whereas
> Array#sort! sorts the
> | receiver in-place. They does same thing, only
> differs in targets.
>
> | You Array#sample! does pick samples from array,
> IN ADDITION TO
> | removing picked elements from the receiver.
> | Array#sample! does two things at once.
>
> .. and what this seems to me to be saying is that
> the bang has a very specific meaning. It is not
> just about *changes* the receiver, but that the
> receiver is *replaced by* that value which is
> returned by the non-bang version.

I don't think the bang is necessarily that constrained; for example:

irb(main):004:0> a = [1,2,3,4]
=> [1, 2, 3, 4]
irb(main):005:0> a.slice!(2)
=> 3
irb(main):006:0> a
=> [1, 2, 4]

I'd stick with "modifying receivers in-place instead of modifying the
copies", which doesn't necessarily mean a complete replace operation.
And of course it's all part of "danger".[1]


David

[1] Let me sneak in a reference to my blog post about why it's bad
to have un-paired bang methods (which isn't what we're talking about,
but that's why I said 'sneak' :-)

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

-- 
Rails training from David A. Black and Ruby Power and Light:
  *  Advancing With Rails    August 18-21    Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

In This Thread

Prev Next