Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > local vars clobbered by un-run code

Reply
Thread Tools

local vars clobbered by un-run code

 
 
Trans
Guest
Posts: n/a
 
      06-19-2007
Err...

irb(main):001:0> def x; 1; end
=> nil
irb(main):002:0> p x
1
=> nil
irb(main):003:0> if false
irb(main):004:1> x = x() + 1
irb(main):005:1> end
=> nil
irb(main):006:0> x
=> nil

Don't tell me, it's some quirk of the way Ruby works. Sure looks like
a bug though. Just in case:

ruby 1.8.4 (2005-12-24) [i486-linux]

Hmm... I just got a dejavu. Maybe I came across this before.

T.


 
Reply With Quote
 
 
 
 
Trans
Guest
Posts: n/a
 
      06-19-2007


On Jun 18, 10:35 pm, Yukihiro Matsumoto <(E-Mail Removed)> wrote:
> Hi,
>
> It's not a bug. Assignments makes identifiers local variables,
> statically.
>
> matz.


This must be the matz-bot. The answer came instantaneously and, deja-
vu again, I think it's same one I got before

Thanks matz,
T.


 
Reply With Quote
 
 
 
 
Robert Dober
Guest
Posts: n/a
 
      06-19-2007
On 6/19/07, Trans <(E-Mail Removed)> wrote:
>
>
> On Jun 18, 10:35 pm, Yukihiro Matsumoto <(E-Mail Removed)> wrote:
> > Hi,
> >
> > It's not a bug. Assignments makes identifiers local variables,
> > statically.
> >
> > matz.

>
> This must be the matz-bot. The answer came instantaneously and, deja-
> vu again, I think it's same one I got before

Let us see?

Which assignment Matz?

irb(main):001:0> def x;1 end
=> nil
irb(main):002:0> if false then
irb(main):003:1* def x; 2 end
irb(main):004:1> end
=> nil
irb(main):005:0> x
=> 1
irb(main):006:0> def y; 1 end
=> nil
irb(main):007:0> if false
irb(main):008:1> undef y
irb(main):009:1> end
=> nil
irb(main):010:0> y
=> 1

Surely the statements inside if are not executed.

Cheers
Robert
--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

 
Reply With Quote
 
tsela.cg@gmail.com
Guest
Posts: n/a
 
      06-19-2007
On 19 jun, 07:48, "Robert Dober" <(E-Mail Removed)> wrote:
>
> Let us see?
>
> Which assignment Matz?
>
> irb(main):001:0> def x;1 end
> => nil
> irb(main):002:0> if false then
> irb(main):003:1* def x; 2 end
> irb(main):004:1> end
> => nil
> irb(main):005:0> x
> => 1
> irb(main):006:0> def y; 1 end
> => nil
> irb(main):007:0> if false
> irb(main):008:1> undef y
> irb(main):009:1> end
> => nil
> irb(main):010:0> y
> => 1
>
> Surely the statements inside if are not executed.
>


No, but they are parsed. And identifiers are made local variables at
parse time, not at execution time. So if you have an assignment
anywhere, even in a place that will never actually execute, the
identifier used in the assignment will be considered a local variable
by the interpreter.

Christophe.

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      06-19-2007
On 6/19/07, http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> wrote:

>
> No, but they are parsed. And identifiers are made local variables at
> parse time, not at execution time. So if you have an assignment
> anywhere, even in a place that will never actually execute, the
> identifier used in the assignment will be considered a local variable
> by the interpreter.
>
> Christophe.


I guess this can be concluded by what is happening, but is this any
reason to accept this behavior? I honestly do not feel so!

Cheers
Robert

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      06-19-2007


On Jun 19, 4:30 am, "Robert Dober" <(E-Mail Removed)> wrote:
> On 6/19/07, (E-Mail Removed) <(E-Mail Removed)> wrote:
>
>
>
> > No, but they are parsed. And identifiers are made local variables at
> > parse time, not at execution time. So if you have an assignment
> > anywhere, even in a place that will never actually execute, the
> > identifier used in the assignment will be considered a local variable
> > by the interpreter.

>
> > Christophe.

>
> I guess this can be concluded by what is happening, but is this any
> reason to accept this behavior? I honestly do not feel so!


I do not feel so either. But, I've also learned that Ruby just has
some quirks. Matz wouldn't had done it this way unless there was a
very real need to do so. Now, that's not to say he might not have
missed a better solution, so it's still worth discussing if anyone has
one.

T.


 
Reply With Quote
 
Ian Whitlock
Guest
Posts: n/a
 
      06-19-2007
Trans wrote:

>
> Don't tell me, it's some quirk of the way Ruby works. Sure looks like
> a bug though. Just in case:
>
> ruby 1.8.4 (2005-12-24) [i486-linux]
>
> Hmm... I just got a dejavu. Maybe I came across this before.
>
> T.


T all you showed is that sometimes the programmer must be responsible
for knowing whether he wants to reference a function or a variable.

Consider:

def x
1
end

p x #recognize function call without parens

if false
x = x() + 1 #variable x is created when code parsed
end

p x #reference the variable x which is nil because no assignment was
made
p x() #if the above were the function, how would you reference the
variable?

Result:

1
nil
1

Ian

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      06-19-2007
On 6/19/07, Ian Whitlock <(E-Mail Removed)> wrote:
> Trans wrote:

Tom it just strikes me, your thread and mine about Singleton classes
not being in ancestors and small other things I always see the same
pattern. Rick's blog entry is another example, always the same
pattern, it is the pattern of imperfection which is the *only* thing
that slightly bothers me in Ruby:


Consistency.

Maybe, probably I am wrong, but I feel that when it comes to these
subtle things Ruby is lacking consistency.

There just seems no reason for some behavior and your example above is
a classical example. You ask yourself why and you cannot find an
answer.

And worst of all, you have to remember!!

Still a great, great language of course.

Robert

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      06-19-2007


On Jun 19, 4:02 pm, Ian Whitlock <(E-Mail Removed)> wrote:
> Trans wrote:
>
> > Don't tell me, it's some quirk of the way Ruby works. Sure looks like
> > a bug though. Just in case:

>
> > ruby 1.8.4 (2005-12-24) [i486-linux]

>
> > Hmm... I just got a dejavu. Maybe I came across this before.

>
> > T.

>
> T all you showed is that sometimes the programmer must be responsible
> for knowing whether he wants to reference a function or a variable.


One of things I always liked about Ruby is the fact the local vars and
methods are, in a certain sens of the word, polymorphic. Where a
method is being called, I can easily change it to be a variable. I
don't have to go thru the code and remove ()s or vice versa.

def chip
"%s chip"
end

def good
chip = "forget the %s chip"
puts chip % "good"
end

So if you can do that, it would seem reasonable that one could do so
conditionally as well. I find it odd that x is being setup as a local
var before ever being assigned as such. That's quite declarative for a
language that tends to shuns such things.

T.


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      06-19-2007


On Jun 19, 4:27 pm, "Robert Dober" <(E-Mail Removed)> wrote:
> On 6/19/07, Ian Whitlock <(E-Mail Removed)> wrote:> Trans wrote:
>
> Tom it just strikes me, your thread and mine about Singleton classes
> not being in ancestors and small other things I always see the same
> pattern. Rick's blog entry is another example, always the same
> pattern, it is the pattern of imperfection which is the *only* thing
> that slightly bothers me in Ruby:
>
> Consistency.
>
> Maybe, probably I am wrong, but I feel that when it comes to these
> subtle things Ruby is lacking consistency.
>
> There just seems no reason for some behavior and your example above is
> a classical example. You ask yourself why and you cannot find an
> answer.
>
> And worst of all, you have to remember!!
>
> Still a great, great language of course.


That is true. Ruby does have some rough edges. Though I chalk much of
it up to the fact that convenience and flexibility often comes with a
price of a few quirks.

T.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Use self.vars in class.method(parameters, self.vars) caccolangrifata Python 18 07-22-2011 10:22 PM
How do I declare global vars or class vars in Python ? Linuxguy123 Python 7 02-20-2009 06:45 PM
app vars and cache vars Jon ASP .Net 3 12-14-2004 08:52 PM
Comments get clobbered in transformation Collin VanDyck Java 1 10-15-2003 03:12 PM
VS.NET Bug - event handlers clobbered repeatedly SteveLB ASP .Net 0 08-08-2003 04:02 AM



Advertisments