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

Hi,

On Fri, August 08, 2008, 21:08:00, "David A.
Black" <[e-mail]> wrote:

|Hi --
|On Fri, 8 Aug 2008, [e-mail] wrote:
|>
|> I think that the verb/noun difference IS at the
|> heart of it. 
|
|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.

One of the things the appealed to me about
'sample' was its noun/verb duality, but that does
seem to break down a bit here.

|> I also thought a lot about Matz's response:
|>
|> | 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:

Nor do I. I was just trying to get to the bottom
of Matz's comments. He is clearly against the
sample! method and I just wanted to understand the
basis of that objection.

|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]

Doh! Yes, I had missed the analogy with slice. And
in fact slice! and sample! are so similar that I
am really at a loss to understand what is wrong
with the latter.

| I'd stick with "modifying receivers in-place"
instead of 
| "modifying the copies", which doesn't
necessarily mean a
| complete replace operation.

Absolutely right. I scanned fxri for all the !
methods and they *all* modify the receiver. (Well,
*nearly* all ;-) There are a couple of odd ones
like Tempfile#close!, where it is not really
meaningful to 'modify' the receiver, but even they
seem to do the next best thing - unlinking, in
this particular example.)

In truth, though, the more I think about these
methods, the more I feel that they are all so
simple (to the point of being trivial) that I
agree with the view that the clutter they add
outweighs the value.

graeme
_______________
PS [At the risk of being off-topic]
I read and agreed with the blog (except where it
says that not all ! methods modify the receiver -
they do seem to, with the couple of exceptions
noted above).

| And of course it's all part of "danger".[1]

But this part causes me some concern. As you state
in the blog, it is a subjective (and therefore our
purposes imprecise) term. What we are saying is
that to qualify for a ! a method must satisfy some
criteria which depends on how you are using it.
Not a healthy statement in a programming language
description IMHO.
    
As an example, if I inadvertently use
    
acct = account.fetch(12345)
acct.credit(value)      # error - should be
acct.credit!(value)
acct.save

it would appear that the non-bang version is the
"dangerous" one.

I think the danger here is the use of the word
"danger". 

But you are right - we are not talking about this.