On Monday 17 January 2005 11:19 am, David A. Black wrote:

| It strikes me as a perfectly idiomatic way of writing a "getter"
| method with a default value.  I call it "polite" because it sets up a
| situation where what will happen is that the object will be sent a
| message and handle it.

But its not just idiomatic, its functional. For instance what if nil is a 
valid value. But worse every time you read the value via the getter you are 
also potentially calling a setter too. Its not a complete substitute for 
initializing the instance var. Also problems can arise in meta-programming 
when one does use instance_variable_get.

| How would you have done it?

There really needs to be a way to guarantee an initialization at each level of 
the class hierarchy. Probably the best way is a special method like 
#initialize_always. (I think robert may have had a better name for it). Hmmm, 
maybe #initialize_with_super. Because that's basically the idea: super is 
automatically called.

On the other hand, maybe there is objection to this in that arbitrary methods 
can be called? I don't see that being a problem, but since the goal (AFAIC) 
is just to provided default values to instance var upon initialization, I 
would not mind another way. I just threw out the @@var as a possibility after 
you proposed to do away with them (which like I said is okay by me).

| > If a class defines _instance_ methods in surely has a right to define
| > default values for _instance_ vars. In fact that's exactly what this hack
| > is trying to do (in its own lame way). But take the static example:
|
| You're arguing from a shaky semantic analogy: the word "instance"
| appears in two contexts, so why shouldn't they be viewed as identical?
| Well, because they're not :-)  If you argue your way out of thinking
| that objects should have instance variables that are truly theirs,
| then I think you'll end up in a situation where a lot of people start
| suggesting that Ruby objects need instance variables that are truly
| theirs....

But that's not what I am suggesting. Object have instance vars, just as object 
have instance methods. Classes define what those instance methods are. 
Therefore I see no reason why they can't also define what the initial values 
of the instance vars are. That's all I was trying to say.

| >  def x
| >    10
| >  end
| >
| > Is this "10" in the in the jurisdiction of the class or the object?
|
| I don't understand the question.  It's part of a method.  I guess it's
| in the jurisdiction of whoever wrote the method -- ?

By jurisdiction I meant "theirs" per you previous paragraph. I was just trying 
to provided an "in the cross-roads" kind of example. The 10 is part of the 
object, but defined by the class, kind of thing.

| My overall point, I guess, is that instance variables, design-wise,
| are not in a state of limbo waiting for us to decide what their nature
| should be.

I don't see the limbo. Hope my above explanation clarifies why.

T.