Exactly. This discussion has confirmed my tendency to only teach
&&, || (for boolean expressions, assignments with defaults, ...)
and leave control flow to if/unless.
Myself, I use constructs like `do_something or do_other'
very seldom anyway.
Yup. The way && and || work is like almost all other languages. But
because "and" and "or" has lower precedence and "and" has the same
precedence as "or", I almost never use them. (If you switch from
language to language, you know what I mean.)
Consider the difference between "x = true && false" and "x = true and
false". Since && has HIGHER precedence than =, "x = true && false" is
equivalent to "x = (true && false)", just as you might expect.
Why would I expect that? Why would I even *use* assignments in "if"
statements?
I think Dave was not talking about an assignment in an if statement,
just a "pure" assignment of a boolean expression to a variable.
[...]
Maybe my programming style is totally out of fashion, but my "if"
statements usually look like this:
if <some expression> and (<some expression> or <some expression>)
...
end
[...]
When I want to do "magic" like
var = val || alt
then I do use &&/||. But this is a very different context.
What I do not like about this approach is that the used operators
depend on the context (condition in if statement / condition assigned
to a variable), not on the purpose (condition vs. control flow).
Every time you want to refactor an if statement by pulling out the
condition into a variable you have to change operators:
if condition_one and condition_two
...
end
becomes
valid = condition_one && condition_two
if valid
...
end
I totally agree with Jan E.
What reason is there for Ruby to have "and" and "or" if you aren't supposed to use them?
The problem for most people is that they fail to realize that they are not aliases for && and || respectively.
Since they are not aliases they provide different functionality and someone interested in programming with Ruby should research when and how to use them. Again, Jan E. Came up with a good example.
One thing that I don't like with ruby precedence however, is that ruby developers decided to give "and" and "or" the same precedence.
In my opinion, "or" should have lower precedence than "and", just like in perl, wich allows you to do things like:
if <e_1> and <e_2> or <e_3> and <e_4>
Knowing that expression 3 and 4 will only be executed if 1 and 2 are not true.
I suppose that they went for left to right readability so you have to evaluate everything as you read it.
so to get something similar in ruby you have to write:
if (<e_1> and e_2>) or (<e_3> and <e_4>)
--DavidG
PS: why is there not (or at least an easy to find) an operator precedence table in ruby-doc.com?
The ones I found where in different, not official looking websites.
1. The Ruby Language
2. Ruby - Operators
···
On Sat 05 Jan 2013 09:56:38 PM MST, Jan E. wrote:
Dave Aronson wrote in post #1091178:
No! No! 1000.times :no!
Consider the difference between "x = true && false" and "x = true and
false". Since && has HIGHER precedence than =, "x = true && false" is
equivalent to "x = (true && false)", just as you might expect.
Why would I expect that? Why would I even *use* assignments in "if"
statements?
Sorry, but if you use assignments in "if" statements (much too obscure)
without explicit parenthesis (even worse), then I'd say *this* is your
problem, not the implicit operator precedence you somehow consider to be
"wrong".
Maybe my programming style is totally out of fashion, but my "if"
statements usually look like this:
if <some expression> and (<some expression> or <some expression>)
...
end
With <some expression> being a pure expression (no change of state). In
that context, I want a very low precedence to make sure that each <some
> is evaluated *before* and/or takes action.
And I believe this is the sane way of writing "if" statements.
When I want to do "magic" like
var = val || alt
then I do use &&/||. But this is a very different context.
Why would I expect that? Why would I even *use* assignments in "if"
statements?
Sorry, I missed that you were specifically speaking of "if"
statements. But even so:
Using &&/|| in some parts and and/or in other parts, is confusing and
fragile. If I have to make a complex boolean expression, and
something goes wrong, I sometimes extract parts out into an assignment
to a temp var, so I can grab that subexpression in a debugger. If
that subexpression uses and/or, that will play merry hell with trying
to get the actual value of the expression.
Sorry, but if you use assignments in "if" statements (much too obscure)
Agreed, and I said so even back in my days of hacking C, where it used
to be fairly common.
-Dave
···
On Sat, Jan 5, 2013 at 11:56 PM, Jan E. wrote:
--
Dave Aronson, the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/\.
Exactly. This discussion has confirmed my tendency to only teach
&&, || (for boolean expressions, assignments with defaults, ...)
and leave control flow to if/unless.
Myself, I use constructs like `do_something or do_other'
very seldom anyway.
Yup. The way && and || work is like almost all other languages. But
because "and" and "or" has lower precedence and "and" has the same
precedence as "or", I almost never use them. (If you switch from
language to language, you know what I mean.)
Regards,
Bill
Hi,
I am a C programmer and have to comply the code with MISRA <http://en.wikipedia.org/wiki/MISRA_C> rules.
According to these rules programmers should not rely on precedence of the
operators. They state to use [redundant] parenthesizes () instead.
So when an expression is too complicated, ( and ) would be in help.
···
--
Regards,
Ivan Cenov
OKTO-7 Co. Bulgaria
imc@okto7.com, i_cenov@botevgrad.com
mobile:+359888761080,
phone:+35972366161, fax:+35972366262
Let's make better business with http://www.redmine.org
Couldn't disagree with you MORE.
Assigning the result of an expression is very Rubyish. Assigning the result of an if statement is an elegant way of eliminating redundant assignments.
x = if y && z
1
else
2
end
vs
x = 0
if y && z
x = 1
else
x = 2
end
I agree that "and" / "or" are used for flow control NOT logical expressions.
Henry
···
On 6/01/2013, at 5:56 PM, Jan E. <lists@ruby-forum.com> wrote:
Sorry, but if you use assignments in "if" statements (much too obscure)
without explicit parenthesis (even worse), then I'd say *this* is your
problem, not the implicit operator precedence you somehow consider to be
"wrong".
What I do not like about this approach is that the used operators
depend on the context (condition in if statement / condition assigned
to a variable), not on the purpose (condition vs. control flow).
Exactly.
What reason is there for Ruby to have "and" and "or" if you aren't supposed
to use them?
Just because it's there, doesn't mean it's good. For instance, why
would the world have cold germs if we weren't supposed to catch them?
(Yeah, I know, catching a cold is a good thing, from the POV of a cold
virus.) Heck, I've got a presentation with over a dozen nasty little
gotchas in Ruby.
One thing that I don't like with ruby precedence however, is that ruby
developers decided to give "and" and "or" the same precedence.
Yeah, that's very inconsistent with && vs. ||. Yet more reason not to use them.
-Dave
···
On Sun, Jan 6, 2013 at 3:33 AM, <sto.mar@web.de> wrote:
On Sun, Jan 6, 2013 at 3:43 AM, David Gamba <davidgamba@gmail.com> wrote:
--
Dave Aronson, the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/\.
You're confusing assigning the result of an if with an assignment within an if. It's the second people are having problems with.
···
On Mon, 07 Jan 2013 02:23:14 +0100, Henry Maddocks <hmaddocks@me.com> wrote:
Couldn't disagree with you MORE.
Assigning the result of an expression is very Rubyish. Assigning the result of an if statement is an elegant way of eliminating redundant assignments.
