Can you elaborate more on what sort of bugs is likely to occur? (I.e.,
under what situation does “@@a ||= value” create a danger of creating the
class variable at the wrong level?) And if it is a problem with class
variables, why is it not a problem with instance variables?
Regards,
Bill
···
=========================================================================
Kent Dahl kentda@stud.ntnu.no wrote:
That might be a bad idea, since class variables are more “magical” than
both instance variables and local variables.
The inheritance hierarchy level where the class variable is first
defined decides where it is visible. This is not a problem with local
variables nor instance variables. Although it is alot more verbose,
using the “@@a = 1 unless defined? @@a” trick gives you the same
functionality, but is easier to spot while reading, if it causes a bug.
This is very interesting. Should Ruby be more consistent in this respect?
That might be a bad idea, since class variables are more “magical” than
both instance variables and local variables.
The inheritance hierarchy level where the class variable is first
defined decides where it is visible. This is not a problem with local
variables nor instance variables. Although it is alot more verbose,
using the “@@a = 1 unless defined? @@a” trick gives you the same
functionality, but is easier to spot while reading, if it causes a bug.
Can you elaborate more on what sort of bugs is likely to occur? (I.e.,
under what situation does “@@a ||= value” create a danger of creating the
class variable at the wrong level?)
I am no expert at this stuff, but I ran into something like this when I
used the “unless defined?” way. A quick example:
···
#=================================
class Base
def show
puts @@a
end
end
class Derived < Base
@@a = 2 unless defined? @@a
def show_derived
puts @@a
end
end
class Base
@@a = 1 unless defined? @@a
end
Base.new.show #=> 1
Derived.new.show #=> 1
Derived.new.show_derived #=> 2
#=================================
And if it is a problem with class
variables, why is it not a problem with instance variables?
Because instance variables simply belong to the current object. Class
variables has a whole nother dimension to get lost in; the class
hierarchy. A class variable is visible only to the class it was defined
in and below, IIRC. Defining a class variable above in the hierarchy
creates a new one. (Such as shown in the example above)
The short version then is that the ||= is so short and inconspicous that
it would help to hide such bugs from you. Using “unless defined?” is
more verbose, fitting to the amount of headache it can induce. (In my
case, it was while reloading libraries using “load” in a program I was
editing while it was running.)
The earlier threads on class variables versus class instance variables
might shine more light on the subject.
–
([ Kent Dahl ]/)_ ~[ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
I am not too sure which way it has been made consistent. Does ||= work
on all variables similarly now? It looks like it, from what I can gather
from the patch source… cvs update, compile … yup, ||= works on all
now.
If all types of variables now work with ||=, that isn’t necessarily a
bad idea, but writing Ruby code that sets a class variable using ||=
somewhere which might cause it to be defined at the wrong hierarchy
level might be a bad idea. As for what Ruby should do, it really is a
weighing of “shooting foot” versus “ease of toe nail cutting” that it
appears Matz already has made a call on.
I will probably succumb to using the terser ||= with class variables
myself over time, but I have already learned the pitfall. Don’t know
about nubies, as YMMV.
At Sat, 12 Oct 2002 00:57:04 +0900, > Kent Dahl wrote:
The inheritance hierarchy level where the class variable is first
defined decides where it is visible. This is not a problem with local
variables nor instance variables. Although it is alot more verbose,
using the “@@a = 1 unless defined? @@a” trick gives you the same
functionality, but is easier to spot while reading, if it causes a bug.
Oops, 1.7 behavior has changed. Bad idea?
[ruby-talk:50421] & [ruby-dev:18278]
–
([ Kent Dahl ]/)_ ~[ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
I am not too sure which way it has been made consistent. Does ||= work
on all variables similarly now? It looks like it, from what I can gather
from the patch source… cvs update, compile … yup, ||= works on all
now.
The root of the problem might be:
irb(main):001:0> a
NameError: undefined local variable or method `a’ for
#Object:0x258d558
from (irb):1
irb(main):002:0> @a
nil
irb(main):003:0> @@a
NameError: uninitialized class variable @@a in Object
from (irb):3
But then why:
irb(main):008:0> b||true
NameError: undefined local variable or method `b’ for
#Object:0x258d558
from (irb):8
irb(main):009:0> b||=true
It seems like ||= has some extra hacking. Any ideas?
Using ruby-1.7.4 under WinME, downloaded from PragmaticProgrammer
What about the above with the CVS version?
ps: When will be a newer installer available under windows?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
I will probably succumb to using the terser ||= with class variables
myself over time, but I have already learned the pitfall. Don’t know
about nubies, as YMMV.
… of course, every Ruby Nuby should run with -w, which would warn
about this. Now, if only I could get into the habit of doing the same.
···
–
([ Kent Dahl ]/)_ ~[ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
In message “Re: Different Behavior of Class Variables w.r.t ||=” on 02/10/12, Kent Dahl kentda@stud.ntnu.no writes:
Oops, 1.7 behavior has changed. Bad idea?
[ruby-talk:50421] & [ruby-dev:18278]
If all types of variables now work with ||=, that isn’t necessarily a
bad idea, but writing Ruby code that sets a class variable using ||=
somewhere which might cause it to be defined at the wrong hierarchy
level might be a bad idea. As for what Ruby should do, it really is a
weighing of “shooting foot” versus “ease of toe nail cutting” that it
appears Matz already has made a call on.
Class variables themselves have same kind of problem.
def foo
@@c = 42
end
does not raise error nor warning. Let me think it again.
It seems like ||= has some extra hacking. Any ideas?
The line
a ||= b
is just syntactic sugar for
a = a || b
Now, it looks like the new way is that the left side of the assignment
(the l-value) is evaluated first, resulting in creation of the variable
if it wasn’t already there. Then the right hand side is evaluated and
the assignment itself is done. Given a mental model with this order of
events, the workings of ||= doesn’t appear too magic or hackish to me,
atleast. If the model was different, I would be scared to think what
a = a
would be parsed as, not to mention
def a; 1;end
a = a
Using ruby-1.7.4 under WinME, downloaded from PragmaticProgrammer
What about the above with the CVS version?
Same messages with
ruby 1.7.3 (2002-10-10) [i686-linux]
···
–
([ Kent Dahl ]/)_ ~[ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 5. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
I like that idea! It would be interesting to see how many messages would
appear on the list if that change was made without mentioning it in the next
version that’s released :-).
I’m going to go and replace my ruby executable with a script that calls the
original with “-w”, to see whether I start picking up problems in code I’ve
already written !!
H.
···
On Sat, 12 Oct 2002 05:24, Gavin Sinclair wrote:
Funny, in every language I know, warnings are off by default, and then
people have to constantly advise other people to turn them on.
I think Ruby should have them on by default, and use a command-line switch
to suppress them.
“ruby bad.rb” => 17 warnings by default
“ruby -w 17 bad.rb” => no warnings
“ruby -w 16 bad.rb” => “Warning: Expected 16 warnings, but there were 17!”
“ruby -w 18 bad.rb” => “Warning: Expected 18 warnings, but there were 17!”
– Nikodemus
···
On Sat, 12 Oct 2002, Gavin Sinclair wrote:
I think Ruby should have them on by default, and use a command-line switch to
suppress them.
Funny, in every language I know, warnings are off by default, and then
people have to constantly advise other people to turn them on.
I think Ruby should have them on by default, and use a command-line switch
to suppress them.
I like that idea! It would be interesting to see how many messages would
appear on the list if that change was made without mentioning it in the next
version that’s released :-).
I’m going to go and replace my ruby executable with a script that calls the
original with “-w”, to see whether I start picking up problems in code I’ve
already written !!
H.
As James pointed out, you can use the RUBYOPT environment variable.
Saturday, October 12, 2002, 1:34:06 PM, you wrote:
I think Ruby should have them on by default, and use a command-line switch to
suppress them.
How about:
“ruby bad.rb” =>> 17 warnings by default
“ruby -w 17 bad.rb” => no warnings
“ruby -w 16 bad.rb” => “Warning: Expected 16 warnings, but there were 17!”
“ruby -w 18 bad.rb” => “Warning: Expected 18 warnings, but there were 17!”
I think Ruby should have them on by default, and use a
command-line switch to suppress them.
Where do you put the switch if you’ve set a file as executable and run it
without specifying the interpreter?
$VERBOSE = false
Why not just set your RUBYOPT value to include warnings?
I think the point was to encourage people to write code that does not
generate warnings.
It might be interesting, as the number of warnings/errors increase, to
have different levels of warnings. The default warning level could be
somewhere in the middle, and the user could increase/decrease this level
as necessary.
Paul
···
On Sat, Oct 12, 2002 at 08:12:27AM +0900, JamesBritt wrote:
