I've written up some ruby gotchas that have come up while using ruby.
I'm wondering if there are any other gotchas that I should be aware of.
The list is available at:
http://hasno.info/2006/12/14/ruby-gotchas-and-caveats
I was considering adding &&= to the list as it's functionality seemed a
bit odd to me at first.
--mark
···
--
sic transit gloria et adulescentia
blog | http://hasno.info
wiki | http://wiki.hasno.info
Mark Guzman wrote:
I've written up some ruby gotchas that have come up while using ruby.
I'm wondering if there are any other gotchas that I should be aware of.
The list is available at:
http://hasno.info/2006/12/14/ruby-gotchas-and-caveats
I was considering adding &&= to the list as it's functionality seemed a
bit odd to me at first.
--mark
From the 'Ruby way':
foo = false
bar = true
baz = foo or bar
baz ends up false (because = has greater priority than or)
Cheers,
Peter
···
__
http://www.rubyrailways.com
Mark Guzman wrote:
I've written up some ruby gotchas that have come up while using ruby.
I'm wondering if there are any other gotchas that I should be aware of.
The list is available at:
http://hasno.info/2006/12/14/ruby-gotchas-and-caveats
I was considering adding &&= to the list as it's functionality seemed a
bit odd to me at first.
--mark
The follow gets on my nerves a bit
class A
def foo
yield "foo"
end
end
a = A.new
a.foo do |a|
puts a
end
a.foo do |a|
puts a
end
···
---
foo
test.rb:12: undefined method `foo' for "foo":String (NoMethodError)
---
Arguments to blocks are not scoped locally if the
name already exists in the outer scope. I think this
might be changing in Ruby 2.0???
--
Brad Phelan
http://xtargets.com
That sucks. Why would anyone want = to be evaluated before anything else?
I want to be enlightened.
Cheers,
Luciano
···
On 12/19/06, Peter Szinek <peter@rubyrailways.com> wrote:
foo = false
bar = true
baz = foo or bar
baz ends up false (because = has greater priority than or)
reason not to. Got it. That's a good one to know.
irb(main):001:0> a = false
=> false
irb(main):002:0> b = true
=> true
irb(main):003:0> c = a or b
=> true
irb(main):004:0> puts c
false
=> nil
irb(main):001:0> a = false
=> false
irb(main):002:0> b = true
=> true
irb(main):003:0> c = a || b
=> true
irb(main):004:0> puts c
true
=> nil
···
On 12/19/06, Peter Szinek <peter@rubyrailways.com> wrote:
Mark Guzman wrote:
> I've written up some ruby gotchas that have come up while using ruby.
> I'm wondering if there are any other gotchas that I should be aware of.
> The list is available at:
> http://hasno.info/2006/12/14/ruby-gotchas-and-caveats
>
> I was considering adding &&= to the list as it's functionality seemed a
> bit odd to me at first.
> --mark
>
From the 'Ruby way':
foo = false
bar = true
baz = foo or bar
baz ends up false (because = has greater priority than or)
Cheers,
Peter
__
http://www.rubyrailways.com
interesting. So instead of 'or' always use || unless I've got a good
The point is that 'or' and 'and' have /lower/ precedence than anything else, so that they can be used to chain complete expressions together. This is a Perl-ism, to my knowledge and a number of common Perl idioms are based on this. (...like, 'open(my $handle, $filename) or die'). I'm a nuby here, but I haven't seen the weak 'and' and 'or' used much in Ruby - at least, not in the same circumstances where I'm used to seeing it in Perl code.
Cheers,
TomP
···
On Dec 19, 2006, at 9:58 PM, Luciano Ramalho wrote:
On 12/19/06, Peter Szinek <peter@rubyrailways.com> wrote:
foo = false
bar = true
baz = foo or bar
baz ends up false (because = has greater priority than or)
That sucks. Why would anyone want = to be evaluated before anything else?
Luciano Ramalho wrote:
foo = false
bar = true
baz = foo or bar
baz ends up false (because = has greater priority than or)
That sucks.
You can't generalize to everybody just because it sucks for you 
Why would anyone want = to be evaluated before anything else?
The question is not why would anyone want this (btw why not? btw2 this
is exactly what happened here: = was evaluated before or) - but rather
'why it is more logical for someone that the rvalue is computed first
then passed to the lvalue'. Hmm, maybe because it is so in the languages
from where the OP comes from? (At least Java, just tested... i.e. this code:
boolean y = false;
boolean z = true;
boolean x = y || z;
System.err.println(x);
prints 'true'
(I did not write a single line of C# code yet but I guess it's the same
there).
Cheers,
Peter
···
On 12/19/06, Peter Szinek <peter@rubyrailways.com> wrote:
__
http://www.rubyrailways.com
> foo = false
> bar = true
>
> baz = foo or bar
>
> baz ends up false (because = has greater priority than or)
That sucks. Why would anyone want = to be evaluated before anything else?
Dude, the creator of the language reads this list. That doesn't suck,
you just don't understand it. Have some manners.
I want to be enlightened.
I want a pet monkey. Does that obligate you to provide me with one?
···
--
Giles Bowkett
http://www.gilesgoatboy.org
http://gilesgoatboy.blogspot.com
Hi --
> Mark Guzman wrote:
>> I've written up some ruby gotchas that have come up while using ruby.
>> I'm wondering if there are any other gotchas that I should be aware of.
>> The list is available at:
>>http://hasno.info/2006/12/14/ruby-gotchas-and-caveats
>> I was considering adding &&= to the list as it's functionality seemed a
>> bit odd to me at first.
>> --mark
> The follow gets on my nerves a bit
> class A
> def foo
> yield "foo"
> end
> end
> a = A.new
> a.foo do |a|
> puts a
> end
> a.foo do |a|
> puts a
> end
> ---
> foo
> test.rb:12: undefined method `foo' for "foo":String (NoMethodError)
> ---
> Arguments to blocks are not scoped locally if the
> name already exists in the outer scope. I think this
> might be changing in Ruby 2.0???I think so. I believe that I and Guy Decoux are the only people who
will miss it 
David
For what reasons will you miss it? I am sure Matz had it that way for a
reason and I don't
claim to be enlightened enough to say it is wrong. Tt just doesn't fit
with the way I would
expect it to work. Locally scoped seems more natural.
···
On 20 Dec, 18:01, dbl...@wobblini.net wrote:
On Thu, 21 Dec 2006, Brad Phelan wrote:
--
Q. What's a good holiday present for the serious Rails developer?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
aka The Ruby book for Rails developers!
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
Thanks, Tom. This is exactly the sort of explanation I was looking for.
Folks, I was not trying to bash ruby, just trying to figure out why
something that looked very strange to me is the way it is.
Cheers,
Luciano
···
On 12/20/06, Tom Pollard <tomp@earthlink.net> wrote:
The point is that 'or' and 'and' have /lower/ precedence than
anything else, so that they can be used to chain complete expressions
together. This is a Perl-ism, to my knowledge and a number of
common Perl idioms are based on this. (...like, 'open(my $handle,
$filename) or die').
Think of them as the inverse versions of the postfix "if" and "unless"
a = foo.call or puts "died"
puts "died" unless a = foo.call
a = foo.call and puts "succeeded"
puts "succeeded" if a = foo.call
martin
···
On 12/20/06, Tom Pollard <tomp@earthlink.net> wrote:
The point is that 'or' and 'and' have /lower/ precedence than
anything else, so that they can be used to chain complete expressions
together. This is a Perl-ism, to my knowledge and a number of
common Perl idioms are based on this. (...like, 'open(my $handle,
$filename) or die'). I'm a nuby here, but I haven't seen the weak
'and' and 'or' used much in Ruby - at least, not in the same
circumstances where I'm used to seeing it in Perl code.
> > baz ends up false (because = has greater priority than or)
>
> That sucks. Why would anyone want = to be evaluated before anything else?
Dude, the creator of the language reads this list. That doesn't suck,
you just don't understand it. Have some manners.
I apologize to everyone and specially to Matz for being rude while
remarking on a language feature.
I was a bit shocked by the "or" behaviour until Tom reminded me of the
"do or die" idiom in Perl, that's all.
If I thought Ruby sucked I wound't be using it and reading this list daily.
> I want to be enlightened.
I want a pet monkey. Does that obligate you to provide me with one?
No. But that doesn't mean I can't give you a monkey if I want.
Peace,
Luciano
···
On 12/20/06, Giles Bowkett <gilesb@gmail.com> wrote:
Luciano Ramalho wrote:
Thanks, Tom. This is exactly the sort of explanation I was looking for.
Folks, I was not trying to bash ruby, just trying to figure out why
something that looked very strange to me is the way it is.
Sorry Lucio, I have misinterpreted your mail (I have thought you are
actually arguing that Ruby's handling of 'or' vs '=' is the natural way)
and after re-reading I realized that you were upset about quite the
opposite thing...
Cheers,
Peter
···
__
http://www.rubyrailways.com
Ah, sorry, I missed this.
···
On 12/20/06, Luciano Ramalho <ramalho@gmail.com> wrote:
Thanks, Tom. This is exactly the sort of explanation I was looking for.
Folks, I was not trying to bash ruby, just trying to figure out why
something that looked very strange to me is the way it is.
Cheers,
--
Giles Bowkett
http://www.gilesgoatboy.org
http://gilesgoatboy.blogspot.com
M. Edward (Ed) Borasky wrote:
No. But that doesn't mean I can't give you a monkey if I want.
Pet monkeys suck 
Including monkey butlers and ninjas?
--mark
···
--
sic transit gloria et adulescentia
blog | http://hasno.info
wiki | http://wiki.hasno.info
>> No. But that doesn't mean I can't give you a monkey if I want.
> Pet monkeys suck 
>
Including monkey butlers and ninjas?
--mark
Pet monkeys are awesome, although technically, a monkey butler is more
an employee monkey than a pet monkey. I mean pets are often things you
cuddle, but cuddling your butler would be weird, and cuddling your
ninja, forget about it.
···
--
Giles Bowkett
http://www.gilesgoatboy.org
http://gilesgoatboy.blogspot.com