Syntax: eval( "a = !a) != eval( "a = not a")

x = 23 == 23 && ! y = 42 == 23 #=> false
[x,y] #=> [false, true]
x = 23 == 23 and not y = 42 == 23 #=> false
[x,y] #=> [true, true]

… a coding style that personally gives me the hibby-jibbies, but at
least you have the option of playing with it.

Hi,

Skip this mail unless ruby’s syntax for “not” operator matters to you.

operator not’ precedence, rationale:

x = 23 == 23 && ! y = 42 == 23 #=> false
[x,y] #=> [false, true]
x = 23 == 23 and not y = 42 == 23 #=> false
[x,y] #=> [true, true]

… a coding style that personally gives me the hibby-jibbies, but at
least you have the option of playing with it.

I agree. I have difficulties to admit that not’s precedence would
be different from !'s one just to minimize the need for parenthesis.
That must be the side effect of some other reason.
Or this would be explicitly promoting hard to read code, not at
all rubyish I think.

Tastes vary. I prefer pascal’s style to C’s style. ruby support both
to some extend (i.e. do/end & {}).
I do “if (a = xx) and (b = yy) then” vs “if a = xx && b = yy”, because
parenthesis makes thing clearer for me and others. Expecting source
code readers to memorize unusual operator precedence is risky, it
has to be a useful language specific idiom or else I’d rather avoid it.

The mutate! convention (where ! in the method’s name signals potential
change in the receiving object) is a very nice ruby feature. I feel
like using “not” instead of “!” reinforce the signal.

Anyways, as always, when I am not happy with the syntax, I will
resort to my usual solution: if you cannot change the way the language
looks, at least you can pretty print it the way you want.

My pretty printer already changes :xxx => vvv into xxx: vvv (something
that ruby will support soon, let’s have half the benefit right now !).
I guess it will change "/\s+!\S/ into " not " (it already changes == and
!= into “is” and “isn’t”). Kind of weird, but as I said, tastes vary.

Yours,

Jean-Hugues Robert

···

At 10:23 01/04/2004 +0900, you wrote:


Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17

Man, I had just woken up, and I sent out a truly ugly example. That is
nothing I would ever do in real life, believe me :slight_smile:

how about the imaginary situation where you check the validity of some
objects that you read in from, say, a yaml file:

a.valid? && b.valid? or abort “invalid objects.”

or:

not a.invalid? || b.invalid? or abort “invalid objects.”

these are, I believe, fairly common idioms.

Once you learn the precedence of these “word” boolean operators, it’s
not that hard to remember. Just remember that “and”, “not”, and “or”
have very low precedence, only being higher than language constructs
like do…end, if…else…end, etc.

Oh, and yes, as someone else said, they came from perl. :slight_smile:

–Mark

···

On Mar 31, 2004, at 5:23 PM, Mehr, Assaph (Assaph) wrote:

x = 23 == 23 && ! y = 42 == 23 #=> false
[x,y] #=> [false, true]
x = 23 == 23 and not y = 42 == 23 #=> false
[x,y] #=> [true, true]

… a coding style that personally gives me the hibby-jibbies, but at
least you have the option of playing with it.

Jean-Hugues ROBERT jean_hugues_robert@yahoo.com writes:

I agree. I have difficulties to admit that not’s precedence would
be different from !'s one just to minimize the need for parenthesis.
That must be the side effect of some other reason.
Or this would be explicitly promoting hard to read code, not at
all rubyish I think.

It’s from Perl.

From perl… makes sense (in a perlish way). Thanks.

···

At 21:49 01/04/2004 +0900, you wrote:

Jean-Hugues ROBERT jean_hugues_robert@yahoo.com writes:

I agree. I have difficulties to admit that not’s precedence would
be different from !'s one just to minimize the need for parenthesis.
That must be the side effect of some other reason.
Or this would be explicitly promoting hard to read code, not at
all rubyish I think.

It’s from Perl.


Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17