[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

If statement and if modifier not equivalent?

Mark James

2/19/2006 11:09:00 AM

I was under the impression that the if modifier and the
if statememt were equivalent, but for the following code
calling A.test raises an exception, while calling A.test2
succeeds. This is with Ruby 1.8.4.

class A
def A.test
a if a=1
end

def A.test2
if a=1
a
end
end
end
8 Answers

Sylvain Joyeux

2/19/2006 11:24:00 AM

0

On Sunday 19 February 2006 12:08, Mark James wrote:
> I was under the impression that the if modifier and the
> if statememt were equivalent, but for the following code
> calling A.test raises an exception, while calling A.test2
> succeeds. This is with Ruby 1.8.4.
That's because of the way Ruby decides wether a local variable exists or
not. Basically, a local variable is defined the first time it is assigned
to, so in the first case
> def A.test
> a if a=1
> end
a=1, which defines the local, is seen *after* the 'a' statement. So, 'a'
does not exist and boom

In the second case,
> def A.test2
> if a=1
> a
> end
> end
a=1 is seen before the 'a' statement, so it works

Regards,
Sylvain

Mark James

2/19/2006 11:56:00 AM

0

Sylvain Joyeux wrote:

> That's because of the way Ruby decides wether a local variable exists or
> not. Basically, a local variable is defined the first time it is assigned
> to, so in the first case
>
>> def A.test
>> a if a=1
>> end
>
> a=1, which defines the local, is seen *after* the 'a' statement. So, 'a'
> does not exist and boom

OK, thanks Sylvain. But I would have thought that any examination of
the guarded statement would be delayed until after the condition had
been evaluated. Is a parse like this possible?

David Vallner

2/19/2006 12:39:00 PM

0

Dna Nedela 19 Február 2006 12:58 Mark James napísal:
> OK, thanks Sylvain. But I would have thought that any examination of
> the guarded statement would be delayed until after the condition had
> been evaluated. Is a parse like this possible?
>

Personally, I'd be surprised if the parser paid any attention to much of the
semantics of the parsed text at all - that's what the interpreter is supposed
to do. The variable declaration checking at parse-time seems to be the
exception here.

Syntax ge... gurus, feel free to elaborate.

David Vallner

Yukihiro Matsumoto

2/19/2006 12:58:00 PM

0

Hi,

In message "Re: If statement and if modifier not equivalent?"
on Sun, 19 Feb 2006 21:39:04 +0900, David Vallner <david@vallner.net> writes:

|Dna Nedela 19 Február 2006 12:58 Mark James napísal:
|> OK, thanks Sylvain. But I would have thought that any examination of
|> the guarded statement would be delayed until after the condition had
|> been evaluated. Is a parse like this possible?
|
|Personally, I'd be surprised if the parser paid any attention to much of the
|semantics of the parsed text at all - that's what the interpreter is supposed
|to do. The variable declaration checking at parse-time seems to be the
|exception here.
|
|Syntax ge... gurus, feel free to elaborate.

Agreed with you. But there's a vague possibility that this issue will
be solved in Ruby 2.0 in different manner.

matz.

Garance A Drosehn

2/20/2006 2:24:00 AM

0

On 2/19/06, Mark James <mrj@bigpond.net.au> wrote:
>
> I was under the impression that the if modifier and the
> if statememt were equivalent, but for the following code
> calling A.test raises an exception, while calling A.test2
> succeeds. This is with Ruby 1.8.4.
>
> class A
> def A.test
> a if a=1
> end
>
> def A.test2
> if a=1
> a
> end
> end
> end
>
>
Do you really want 'if a = 1' there, and not 'if a == 1'?

--
Garance Alistair Drosehn = drosihn@gmail.com
Senior Systems Programmer
Rensselaer Polytechnic Institute; Troy, NY; USA

Gregory Brown

2/20/2006 2:58:00 AM

0

On 2/19/06, Garance A Drosehn <drosihn@gmail.com> wrote:

> Do you really want 'if a = 1' there, and not 'if a == 1'?

yes. I imagine so.

in a more complicated example

if ( a = get_something_that_might_be_nil_or_false )
puts a
end

matt.smillie@gmail.com

2/20/2006 1:49:00 PM

0

Which makes the assignment a side-effect of the conditional, and
depending on the context can be an excellent example of bad
side-effects, particularly from a software-engineering point of view,
where the code has to be maintained over any sort of time, by a team.

I think of it as the imperative corollary to duck-typing: if it looks
like a duck and sounds like a duck, it should *be* a duck.

There's a great public example of where this technique can break down
from an attempted hack on the linux kernal a couple of years ago. It's
worth noting that it was only caught because of 1) very tight, very
paranoid peer review, and 2) the secure nature of the project. It
would have gone through unnoticed virtually anywhere else. In my past
life doing telecoms programming, I can remember this exact pattern
being responsible for bringing down a good portion of the US East
Coast's 1-800 (and 900, etc) phone numbers.

To each their own, and if it's code for your own use it's unlikely to
matter, but assignment-as-conditional really, really smells bad to me.

http://kerneltrap.org...

> + if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
> + retval = -EINVAL;

Associated commentary:

> > Setting current->uid to zero when options __WCLONE and __WALL are set? The
> > retval is dead code because of the next line, but it looks like an attempt
> > to backdoor the kernel, does it not?

> It sure does. Note "current->uid = 0", not "current->uid == 0".
> Good eyes, I missed that. This function is sys_wait4() so by passing in
> __WCLONE|__WALL you are root. How nice.

David Vallner

2/21/2006 12:45:00 AM

0

Dna Pondelok 20 Február 2006 14:53 matt.smillie@gmail.com napísal:
> > It sure does. Note "current->uid = 0", not "current->uid == 0".
> > Good eyes, I missed that. This function is sys_wait4() so by passing in
> > __WCLONE|__WALL you are root. How nice.

Ow.

David Vallner