expand = true if expand.nil?

As long as you’re happy to use nil as not set then it should be fine.

This is not a bug, but desired behaviour. In your example, the variable named ‘expand’ gets defined because the compiler, when parsing the statement, sees it on the lhs of an assignment operator. Being defined has nothing to do with the dynamic behaviour of the program. Even in the case

if false
expand=1
end

the variable ‘expand’ would be defined.

By calling
d.increase_n

you prove the statement that “…But if a method uses one, and that method is available to subclasses, then it will still use the variable” because increase_n is defined in the superclass C and does actually increment n. Fari enough.

But when you call
d.show_n

it shows that the method show_n in D can directly access n in its superlcass, when it calls
puts “n is #{@n}”

I mean if n had an attr_accessor and you referred to it directly then show_n could access it (with just n not @n) and it would make sense – since it would be a method call.

But here show_n is directly accessing the instance field n in C with no use of an inherited method.

It looks to me like that @n _is_ effectively inherited. Or unless I’m misunderstanding inherited – another way of saying it is that @n is behaving like a protected field in Java.

I say protected, not public, because while any method in D can get and set @n, you can’t do
d.n = 100 #NoMethodError: undefined method `n=’ for…
on the object.

Note that this direct setting restriction doesn’t affect the inherited/not-inherited argument either way though, because I can’t do this either

c = C.new
c.n = 100 #NoMethodError: undefined method `n=’ for

What I really want to say is: Where’s the quirk here? I’m sure its there but I’m missing it.

How about this:

expand = (expand.nil? ? true : expand)

That’s where the frustration comes in…

– Morgan