From: John Sikora <john.sikora@...>
Date: 2010-07-30T14:13:42+09:00
Subject: Re: .any?{} Behavior

David A. Black wrote:

> As I see it, all? and any? make sense in terms of each other. If
> array.all? is true for a condition, that means that array.any? is false
> for the opposite of the condition:
> 
>    array.all? {|e| cond(e) } == !(array.any? {|e| !cond(e) })
> 
> I think that always holds. If [].all? were false, it would not; it would
> flip from true to false depending on how many elements were in the
> array.
> 
> To put it in more human terms, array.all? for a condition means: there
> is no element in this array which violates the condition. I know that it
> feels more natural to say "Every element in this array meets this
> condition" -- but the problem with that is precisely that there's no
> guarantee that an array has elements, so it's more accurate to phrase it
> in the negative way.

I must admit that I would never have thought of the behavior in this 
manner. But the way that you explain it, it makes sense. When I first 
started using Ruby, which was my first (and so far only) OO language, I 
found it surprisingly difficult to make the switch from procedural to OO 
programming. I really had to change my way of thinking. And this was 
just for OO programming, not to mention the Ruby way of thinking as 
illustated here. So I ask questions and thankfully,
usually someone can set me straight.

> It feels to me like you're expecting all? to do too many things. I would
> either just use all? as it stands, or do something else entirely, like:
> 
>    obj_array.find {|obj| obj.attr_1 == x &&! obj.attr_2 == y }
> 
> which I've probably garbled but you get the idea :-)

Yes, I know what you mean and I actually have thought of doing something 
similar to your code. But a couple of the things that I really like 
about Ruby are 1) the Enumerable module itself,  and 2) the ability to 
string together methods. Well, that and the fact that Ruby is dynamic. 
So I probably am asking all? to do too much in this case, but I love to 
string methods containing code blocks together as in the example I gave. 
So much power in so little space.


> Overriding core methods always has the potential to cause problems,
> because other code (in the interpreter and/or the standard library
> and/or gems and other third-party libraries) may be depending on the
> documented behavior.
> 

Yes, I was afraid someone was going to say this (in fact the next person 
to reply said the same thing). I think I knew deep down that this was 
the case, and that I should leave all? as is.

Thanks,
js
-- 
Posted via http://www.ruby-forum.com/.