Prev: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"
Next: leak tracking x64
From: John Sikora on 30 Jul 2010 01:13
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/.

From: John Sikora on 30 Jul 2010 01:16
John W Higgins wrote:
> I might suggest your better course would be to create a new method
> rather
> than override the existing method. Maybe something like js_any? or
> js_all?
> would be better in that it shows both what it's doing and that it's not
> the
> standard method at the same time. Then you have no issues with any other
> code that depends on the standard methodology in terms of the methods. I
> appreciate the aesthetics are a little lacking but sometimes that a
> small
> price to pay.

After reading your post and the previous post from David, I agree.

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

From: Jarmo Pertman on 30 Jul 2010 08:57
Hello!

I'd have to agree with John on this one. It is really bizarre that
[].any? returns false and [].all? returns true. It is just not what to
expect without reading documentation and thinking about every word
written in there and trying things out in irb.

I love Ruby because most of the time everything just works as you'd
expect without reading any documentation at all and this is not the
case. It just doesn't make sense that asking Ruby to answer the
question "does this empty collection have all elements as 3?" to
return true. Read again the question and you'll understand what i
mean. Again, if i think about Ruby being a very much like a version of
an English language, then this doesn't make sense also.

And since i'd expect it to do what i have been expected then i haven't
thought about this situation ever also. I'd consider this to be
changed in future versions of Ruby, but what am i to decide on such
things :)

It would make sense if [].all? and [].any? would return false. Always.

Jarmo Pertman
-----
IT does really matter - http://www.itreallymatters.net


On Jul 30, 8:16 am, John Sikora <john.sik...(a)xtera.com> wrote:
> John W Higgins wrote:
> > I might suggest your better course would be to create a new method
> > rather
> > than override the existing method. Maybe something like js_any? or
> > js_all?
> > would be better in that it shows both what it's doing and that it's not
> > the
> > standard method at the same time. Then you have no issues with any other
> > code that depends on the standard methodology in terms of the methods. I
> > appreciate the aesthetics are a little lacking but sometimes that a
> > small
> > price to pay.
>
> After reading your post and the previous post from David, I agree.
>
> Thanks,
> js
> --
> Posted viahttp://www.ruby-forum.com/.

From: Xavier Noëlle on 30 Jul 2010 12:54
2010/7/30, Jarmo Pertman <jarmo.p(a)gmail.com>:
> It just doesn't make sense that asking Ruby to answer the
> question "does this empty collection have all elements as 3?" to
> return true. Read again the question and you'll understand what i
> mean. Again, if i think about Ruby being a very much like a version of
> an English language, then this doesn't make sense also.

There's no easy answer to this question, as there is nothing easy
dealing with an empty list. Can you prove that not all elements in []
equal 3 ? You can't, because no element has another value. Thus, this
is true.

At first glance, I would intuitively agree with you, but after a
while, I can't find a mean to prove what may sound obvious to you (but
is not).

--
Xavier NOELLE

From: Joel VanderWerf on 30 Jul 2010 13:18
Xavier No�lle wrote:
> 2010/7/30, Jarmo Pertman <jarmo.p(a)gmail.com>:
>> It just doesn't make sense that asking Ruby to answer the
>> question "does this empty collection have all elements as 3?" to
>> return true. Read again the question and you'll understand what i
>> mean. Again, if i think about Ruby being a very much like a version of
>> an English language, then this doesn't make sense also.
>
> There's no easy answer to this question, as there is nothing easy
> dealing with an empty list. Can you prove that not all elements in []
> equal 3 ? You can't, because no element has another value. Thus, this
> is true.
>
> At first glance, I would intuitively agree with you, but after a
> while, I can't find a mean to prove what may sound obvious to you (but
> is not).

Here's one way to think of it, in terms of an example:

pattern = /.../
tests = [ Test.new(...), ..., Test.new(...) ]
runnable_tests = tests.select {|test| pattern === test.name}

if runnable_tests.all?{|test|test.pass}
puts "Ok!"
else
puts "Failed!"
end
__END__

How do we want this program to work if no tests match the pattern? Is it
a failure case? IMO, it is not.

I don't want to code a special case for runnable_tests.empty?

This seems very English-like to me, but YMMV of course.

 |  Next  |  Last
Pages: 1 2 3 4
Prev: binary encode 7 ([7].pack("C")) as "\007" instead of "\a"
Next: leak tracking x64