Ruby and OOP-design (question of an old "procedural person" ;)

[Dan Doel]

Brian Candler wrote:

>On Mon, Aug 11, 2003 at 02:02:33AM +0900, [email]dblack@superlink.net[/email] wrote:
>
>

>>>Does ruby not have exclusive or? I can't remember at the moment. If it
>>>did, I think the top is the same
>>>as:
>>>
>>>unless a.nil? ^ b.nil?
>>>
>>>Which is still somewhat unclear, I agree.
>>>
>>>

>>I, however, no long agree with myself :-) I just forgot about ^.
>>
>>

>
>However ^ is overloaded, so although it works when comparing false/true with
>false/true, it doesn't with other things; especially since it doubles up as
>a bitwise numeric operator too.
>
>irb(main):001:0> 5 ^ false
>TypeError: cannot convert false into Integer
> from (irb):1:in `^'
> from (irb):1
>
>But it does treat 'nil' as 'false'. So you could say:
>
> if (a && true) ^ (b && true)
> ...
> end
>
>which tests if both a and b are 'true' or both a and b are 'false' in the
>Ruby sense of those terms, but it's still not very pretty. I think it would
>be clearer to write
>
> if (a && b) || (!a && !b)
>
>It's not a problem with nil? anyway. If you want to check whether a and b
>are either both zero or both nonzero, you could do
>
> if (a == 0) == (b == 0)
> ...
> end
>
>

Yeah, I thought of the problem with ^ on the way to lunch.

And I just checked and there's no "xor" equivalent to "and" "or" and
"not", so you can't work around it
that way.

Perhaps an "xor" keyword (or a ^^ logical xor operator) would be handy
to have specifically for this
kind of situation, since there's no way to conveniently do (obj1 xor
obj2) in existance tests.

Then again, I can't think of any places where you'd need to do that.

- Dan

[Rudolf Polzer]

Scripsit ille »Brian Candler« <B.Candler@pobox.com>:

> On Mon, Aug 11, 2003 at 02:02:33AM +0900, [email]dblack@superlink.net[/email] wrote:

> > > Does ruby not have exclusive or? I can't remember at the moment. If it
> > > did, I think the top is the same
> > > as:
> > >
> > > unless a.nil? ^ b.nil?
> > >
> > > Which is still somewhat unclear, I agree.

> >
> > I, however, no long agree with myself :-) I just forgot about ^.

>
> However ^ is overloaded, so although it works when comparing false/true with
> false/true, it doesn't with other things; especially since it doubles up as
> a bitwise numeric operator too.

BTW: why do all C-like languages lack the ^^ operator (boolean XOR)?

> irb(main):001:0> 5 ^ false
> TypeError: cannot convert false into Integer
> from (irb):1:in `^'
> from (irb):1
>
> But it does treat 'nil' as 'false'. So you could say:
>
> if (a && true) ^ (b && true)

if !a ^ !b # since a xor b == (not a) xor (not b)

Well, my common C idioms for this case are:

boolean XOR: !a ^ !b
obfuscated boolean XOR: !a!=!!!b /* no, I am not using that */
convert to boolean: !!a

They all work in Ruby.


--
L: Núper erát medicús nunc ést vispíllo Diáulus:
D: Früher war er Arzt, nun ist Diaulus Totengräber:
L: Quód vispíllo facít - fécerat ét medicús.
D: Was er als Totengräber macht - tat er schon als Arzt. [Martial]

[Brian Candler]

On Mon, Aug 11, 2003 at 03:16:55AM +0900, Dan Doel wrote:

> It was just an example. #nil? could be written that way, although then
> it'd be pointless, since
>
> if obj ...
>
> Would be exactly the same as
>
> if obj.nil? ...

I think you mean 'if obj.notnil?' could be written that way.

if obj...

is equivalent to

unless obj.nil? ...

with the exception of obj == false.

Cheers,

Brian.

[Dan Doel]

Brian Candler wrote:

>On Mon, Aug 11, 2003 at 03:16:55AM +0900, Dan Doel wrote:
>
>

>>It was just an example. #nil? could be written that way, although then
>>it'd be pointless, since
>>
>> if obj ...
>>
>>Would be exactly the same as
>>
>> if obj.nil? ...
>>
>>

>
>I think you mean 'if obj.notnil?' could be written that way.
>
> if obj...
>
>is equivalent to
>
> unless obj.nil? ...
>
>with the exception of obj == false.
>
>Cheers,
>
>Brian.
>
>
>

Right, of course. Most of the time it would be

def nil?
!self
end

Which would be a boolean anyway.

Of course, it's even simpler than that, because you can do:

class Object
def nil?
false
end
end

class NilClass
def nil?
true
end
end

So you really never save any typing at all. #nil? is a bad
example, it seems.

- Dan

[Mike Campbell]

> The big reason for & and && is that && is lazy, while & evaluates all
> its arguments.

In what language(s)? I think that's the case in Java, but not in C/C++ if I
recall correctly, which I might not.

[Mark J. Reed]

On Mon, Aug 11, 2003 at 08:44:23AM +0900, Dan Doel wrote:

> I'm not sure about C, but I would assume it is, because there's no
> booleans in C so it'd be totally useless
> as it would do the exact same thing as &.

No, it wouldn't. C doesn't have a Boolean *type*, but it does
have the idea of truth and falsehood (needed for if statements, etc).
Nonzero is true and zero is false. Which means that this expression:

1 & 2

is false - bitwise AND of 1 and 2 yields 0. Whereas

1 && 2

is true, because both 1 and 2 are true (nonzero). The big difference in C
is that the double-characters are LOGICAL operators, while the single
ones are BIT operators.

However, it happens that the logical operators in C and derivatives
also short-circuit, which means you can do things like

if (p != NULL && strcmp(p->value, key)==0)
{

and not worry about the program blowing up because the strcmp() is called
when p is NULL.

-Mark

[Dan Doel]

Mark J. Reed wrote:

>On Mon, Aug 11, 2003 at 08:44:23AM +0900, Dan Doel wrote:
>
>

>>I'm not sure about C, but I would assume it is, because there's no
>>booleans in C so it'd be totally useless
>>as it would do the exact same thing as &.
>>
>>

>
>No, it wouldn't. C doesn't have a Boolean *type*, but it does
>have the idea of truth and falsehood (needed for if statements, etc).
>Nonzero is true and zero is false. Which means that this expression:
>
> 1 & 2
>
>is false - bitwise AND of 1 and 2 yields 0. Whereas
>
> 1 && 2
>
>is true, because both 1 and 2 are true (nonzero). The big difference in C
>is that the double-characters are LOGICAL operators, while the single
>ones are BIT operators.
>
>However, it happens that the logical operators in C and derivatives
>also short-circuit, which means you can do things like
>
> if (p != NULL && strcmp(p->value, key)==0)
> {
>
>and not worry about the program blowing up because the strcmp() is called
>when p is NULL.
>
>

Yes, very true. I think I need to get more sleep or something.

| and || would work equivalently, since you can't get a | b == 0 unless
a == 0 and b == 0.

& and && would be different, you're right.

And, yes, logical && and || are lazy in C which answers the original
question.

I'm not sure why C doesn't have ^^ for logical xor, since 1 ^ 2 would be 3,
which doesn't work for boolean logic. In Java, for example, though, it
doesn't
make a difference, because only booleans can be used as booleans, so
there's no
reason to have separate logical and bitwise operators, other than clarity of
intent.

Perhaps xor is just so seldom used that people don't care.

- Dan

[Meino Christian Cramer]

Hi, :)

THANK YOU VERY MUCH FOR THE IMMENS RESPONSE TO MY QUESTION!

I am very happy to be on this very communicative list :o) !

Since I am at the very very beginning of Ruby-Programming please
understand, that I only understand the smallest part of the
discussion...

In the meantime I git a sorted list of "my" shortwave transmitters.

I did:

@list.push( [freq, stat, time, days, lang, graf, targ,
loca, powr, azim,rema, stau, modu, na, ca,
sa, eu, af, me, as, au, pa, cira, coco, coun,
long, lati, loco, regi, stn , prst, prog] )

for each input line.

Then I did a

@list.sort_by { |item| [item[0], item[2] ] }

and it works smooth and fast as a ligthning.

The above expressions sorts the broadcasters first on frequency then
on on-air time.

Then I thought of a list first sorted by time and then by frequency
and wrote

@list.sort_by { |item| [item[2], item[0] ] }

and astonishly Ruby quaks ;) with :

swlist:62:in `sort_by': comparison of Array with Array failed (ArgumentError)
from swlist:62

("swlist" is the name of my ruby-script)

I dont understand that...

I am sure that the bug is sitting in front of my monitor...but...

What is it what I did so badly wrong ? X)

Thank you very much for any help in advance !

Keep being Ruby!
Meino

[Mills Thomas (app1tam)]

Here, Here!

If someone has some worthwhile reasons they can share for returning the
values, please do so. Otherwise, I would prefer not giving someone data
they might use that might not be there later. I wrote method that returned
a boolean-like value by returning !(!(something)) just to ensure exactly
true or false. The alternative is just to unnerving! :-)

Drew

> -----Original Message-----
> From: Martin DeMello [mailto:martindemello@yahoo.com]
> Sent: Saturday, August 09, 2003 8:52 AM
> To: [email]ruby-talk@ruby-lang.org[/email]
> Subject: Re: Ruby and OOP-design (question of an old
> "procedural person" ;)
>
>
> Well and good, but they don't document the fact that the
> return value can be used as anything other than a boolean.
> Duck typing or no, I find it conceptually messy to have a
> method called nonzero? return self rather than true - compare
> nil? and zero?. Using the value of self feels like relying on
> an undocumented side effect. (I feel the same way about !
> methods returning nil rather than self when they haven't made
> a change).
>
> martin
>

[Dan Doel]

Mills Thomas (app1tam) wrote:

>Here, Here!
>
>If someone has some worthwhile reasons they can share for returning the
>values, please do so. Otherwise, I would prefer not giving someone data
>they might use that might not be there later. I wrote method that returned
>a boolean-like value by returning !(!(something)) just to ensure exactly
>true or false. The alternative is just to unnerving! :-)
>
>Drew
>

That all depends on what exactly you want the method to do. If #nonzero?
is defined as "returns the
number when not zero, or false otherwise," then it's documented that the
result can be used in that way,
which could possibly be useful in some cases.

If #nonzero? is defined as "returns a true value when not zero, and a
false value otherwise," then there's
no compelling reason to return anything other than true or false
exactly. However, there also isn't much
of a compelling reason _to_ only return true or false exactly, except
for rare cases like
1.nonzero? == 2.nonzero?, and the fact that it unnerves some.

However, many people don't have a problem with it, so perhaps it's just
something you get used to
over time. As long as you test adequately, it shouldn't make a
difference one way or the other in practice.

- Dan

P.S.: The above can be written (1 != 0) == (2 != 0), which is shorter to
type, even, so one could
argue that perhaps #nonzero? ought to provide different functionality,
which it does, currently.

[Carlos]

> Then I thought of a list first sorted by time and then by frequency

> and wrote
>
> @list.sort_by { |item| [item[2], item[0] ] }
>
> and astonishly Ruby quaks ;) with :
>
> swlist:62:in `sort_by': comparison of Array with Array failed (ArgumentError)
> from swlist:62

One or more of your times is nil.

[Meino Christian Cramer]

From: Carlos <angus@quovadis.com.ar>
Subject: Re: Ruby and OOP-design (question of an old "procedural person" ;)
Date: Tue, 12 Aug 2003 22:36:10 +0900


THAT'S IT ! THANKS A LOT ! :))

Meino

>
> One or more of your times is nil.
>
>
>
>