Change in class << for 1.8.0?

Consider this:

#!/usr/bin/env ruby
msg = ARGV.shift

class << msg
def GetName; return self; end
end

puts “msg: #{msg}”
puts “msg.GetName: #{msg.GetName}”

···

ruby --version
ruby 1.7.2 (2002-02-21) [i386-linux]

./test1.8.rb foo
msg: foo
msg.GetName: foo


ruby --version
ruby 1.8.0 (2003-08-04) [i386-linux]

./test1.8.rb foo
./test1.8.rb:5: can’t modify frozen object (TypeError)


I’ve been through the changelog but I’m not familiar enough with Ruby
internals to figure out which entry was relevant :frowning:

I am not freezing msg, and I’m not modifying any other object with this.

Can someone help?

Sorry for the stupid looking prompt> prompt… apparently a corporate
crawler found some references to a couple of our machines from my posts to
this list archived on the web. I guess our machine names are confidentail
.

Consider this:

#!/usr/bin/env ruby
msg = ARGV.shift

try msg = ARGV.shift.dup

I guess the elements of ARGV are immutable?

class << msg
def GetName; return self; end
end

Btw, it’s probably a bad idea to name your methods with leading caps.

Ben

···

On Mon August 4 2003 3:48 pm, Brett H. Williams wrote:

Consider this:

#!/usr/bin/env ruby
msg = ARGV.shift

try msg = ARGV.shift.dup

I guess the elements of ARGV are immutable?

Bingo. Thanks for the tip, problem solved. It didn’t occur to me that
ARGV was the problem. Thanks!

class << msg
def GetName; return self; end
end

Btw, it’s probably a bad idea to name your methods with leading caps.

Yes–copied from the app which prompted the question which is implemented
in C++ with such capitalization. I realize it isn’t the norm, but is there
another reason you say it’s a “bad idea”?

···

On Aug 5, Ben Giddings wrote:

On Mon August 4 2003 3:48 pm, Brett H. Williams wrote:

Well, it may work, but Ruby makes decisions on whether something is a class,
constant, variable, etc. based on leading caps. You aren’t competely free to
name things as you see fit.

irb(main):013:0> def DoIt; puts “done”; end
=> nil
irb(main):014:0> DoIt
NameError: uninitialized constant DoIt
from (irb):14
irb(main):015:0> def doIt; puts “done”; end
=> nil
irb(main):016:0> doIt
done
=> nil

So Ruby has decided that DoIt is a constant in this context, but it knows that
doIt is a method call. On the other hand, if you supply the (normally
optional) parentheses to DoIt it works as expected:

irb(main):017:0> DoIt()
done
=> nil

Maybe if you always use parentheses and stuff you can get away with having
methods that start with an uppercase letter… I just wouldn’t do it because
I don’t want to take chances.

Ben

···

On Mon August 4 2003 5:38 pm, Brett H. Williams wrote:

Yes–copied from the app which prompted the question which is implemented
in C++ with such capitalization. I realize it isn’t the norm, but is there
another reason you say it’s a “bad idea”?

Btw, it’s probably a bad idea to name your methods with leading caps.

Yes–copied from the app which prompted the question which is implemented
in C++ with such capitalization. I realize it isn’t the norm, but is
there
another reason you say it’s a “bad idea”?

Partly just convention, but there are also situations
where the parser gets confused. I think a method name
starting with a capital has to have a receiver, for
instance.

Hal

···

----- Original Message -----
From: “Brett H. Williams” brett_williams@agilent.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, August 04, 2003 4:38 PM
Subject: Re: change in class << for 1.8.0?