I’ve noticed some bugs in ruby (I expect another results)
I tested it under Ruby172-4.exe (downloaded from thePragmaticProgrammer
page), winME
k=‘Hello’
[1,2,3].map {|k| k}
puts k
It prints 3 under ruby1!
Another one:
def a
b=2
end
a()
puts b
prints 2
And the last (for today)
one,two=‘asdf’.split(‘-’) # >> [‘asdf’]
a1,a2=‘’.split(‘-’) # >>
one=‘asdf’ two=nil
a1=nil a2=nil
I don’t see the point why split returns an empty array, when it has a VALID, but empty input string. It should return an array returning one
empty element, so [‘’].
Opinions?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
Yes, using block argument equals to assignment to it.
Another one:
def a
b=2
end
a()
puts b
prints 2
Really? I got this error:
-:6: undefined local variable or method `b’ for #Object:0x402de95c (NameError)
I don’t see the point why split returns an empty array, when it has a VALID, but empty input string. It should return an array returning one
empty element, so [‘’].
Yes, using block argument equals to assignment to it.
But shouldn’t it be local to the block? It may cause nice errors…
If it is available outside the block, it is a Bad Idea™.
This is an issue discussed previously on this list as well as feature
enhancements to Ruby in future versions if I am not mistaken. In the above
code k is defined outside the code block and that is why it’s assignment
within the code block is retained outside of it.
k=‘Hello’
[1,2,3].map {|k| k}
puts k
It prints 3 under ruby1!
Yes, using block argument equals to assignment to it.
But shouldn’t it be local to the block? It may cause nice errors…
If it is available outside the block, it is a Bad Idea™.
This is an issue discussed previously on this list as well as feature
enhancements to Ruby in future versions if I am not mistaken. In the above
code k is defined outside the code block and that is why it’s assignment
within the code block is retained outside of it.
So it won’t change in the future?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
Unfortunately, I haven’t been using Ruby that long but again noticed the
topic discussed. I am sure it is preferable to have a ‘local’ context as
would be expected but it can affect older code. I have confidence that the
individuals running the Ruby show will come up with something to satisfy us
all : )
···
At 03:34 AM 10/3/2002 +0900, you wrote:
k=‘Hello’
[1,2,3].map {|k| k}
puts k
It prints 3 under ruby1!
Yes, using block argument equals to assignment to it.
But shouldn’t it be local to the block? It may cause nice errors…
If it is available outside the block, it is a Bad Idea™.
This is an issue discussed previously on this list as well as feature
enhancements to Ruby in future versions if I am not mistaken. In the above
code k is defined outside the code block and that is why it’s assignment
within the code block is retained outside of it.
This has been discussed in probably hundreds
of posts in the last 2-3 years. The range of
opinions is something like this:
a. It’s a bug
b. It’s a feature
c. It’s an oddity
d. It’s too late to fix it easily
e. Various combinations of the above
Go do a search for “block-local”… that should
turn up lots of insomnia-curing material.
You can browse the just-started list at
“http://www.glue.umd.edu/~billtj/ruby.html” (I will change it to HTML
format based on an input from someone); this is item 3) in the list.
Hopefully you will get fewer Ruby gotcha in the future.
Regards,
Bill
···
=========================================================================
Michael Campbell michael_s_campbell@yahoo.com wrote:
This is a “Ruby Gotcha”. IF you declare a variable before the
block, it uses that one. If you don’t, it creates its own, but its
scope IS the block.
I find this… odd, and I don’t like it, but that’s the way it is.
There was a poll on rubygarden.org, but the results were, ummm, unclear.
Wouldn’t each of the proposed modifications fix it? Then shouldn’t we
try to figure out what is the best one now instead of later? The
sooner we think about it, the better, IMHO.
As for me, I voted for |external;local|
···
On Thu, Oct 03, 2002 at 01:39:46PM +0900, Yukihiro Matsumoto wrote:
I have confidence that the individuals running the Ruby show will
come up with something to satisfy us all : )
I think that’s statistically impossible. ; )
Possible solutions:
All the parameters of the block are local to the block.
Well, this way programs written in past won’t work.
However you can pass values outside the block.
Ability to define block vars local
How to define them local?
Extra typing for future programs.
So either old programs won’t work without modification,or new programs
need extra typing to avoid a probable bug. People will forget these
extra typings and create program bugs.
What about a version-marking system to provide compatibility?
Perl and some others have such a feature. You specify the version you
wrote your script for.
Next release will mark some old features depricated, and the version
after the next version will refuse to work?
So I think versioning maybe an acceptable choice (need 1 row extra
typing at the beginning of the program, or at the command line an extra
switch)
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
a = [1, 2, 3]
b = “I’ll change”
c = “I’m static”
a.each do |b|
# whatever
# can use other vars any way I want
end
here b = 3
a.each do |;c| #whatever #can use other vars any way I want
end
c still the same
Now I see this syntax (or my understanding of it) is broken as you
cannot specify the order in which your vars are assigned…
Maybe
a.each do |:a,b,:c,d|
a and c local
b and d “external” (outer scope)
end
It is better to mark local vars as this way all the existing code works
unmodified. I’ve used ‘:’ cause I cannot think of any other semantics
for it in that position.
You see, it’s still “the Ruby way” as it’s just like before, only with
additional scope markers.
If we want to discriminate between variable usages, it’s either this or “my”…
···
On Thu, Oct 03, 2002 at 10:05:37PM +0900, William Djaja Tjokroaminata wrote:
As for me, I voted for |external;local|
Hi Mauricio,
Isnt’t that using the syntax below contrary to “the ruby way” that we
should be able to create a variable at any time, anywhere?
This has been discussed in probably hundreds