Hi --

On Tue, 18 Jan 2005, trans.  (T. Onoma) wrote:

> On Monday 17 January 2005 10:30 am, David A. Black wrote:
> | Hi --
> |
> | On Mon, 17 Jan 2005, trans.  (T. Onoma) wrote:
> | > On Monday 17 January 2005 09:21 am, David A. Black wrote:
> | > | Yes :-)  You've got one object (M) setting another object's instance
> | > | variables (those of C.new), without the owner-object's consent.  I
> | > | know that there are already things like instance_variable_set and so
> | > | on that can do this... but I personally take a pretty hard line on
> | > | instance variables being strictly the business of the instance whose
> | > | variables they are.  I don't think there should be a proliferation of
> | > | mechanisms for crossing that boundary.
> | >
> | > I understand were your coming form, but in this case I don't think that's
> | > what's happening. The class defines the nature of its instances. So its
> | > not like some other unrelated object getting involved. I just presenting
> | > a way fro a class to define the default values of the instance vars of
> | > its instances. In a way it is kind of like Hash.new blocks.
> |
> | My perspective is that this is already a specific, fully-designed
> | case: every object has instance variables, and they belong to that
> | object.  So when you say "the class defines the nature of its
> | instances", you're backing out into an unnecessarily general and
> | distant view.  My answer is: no, apparently it doesn't, in that sense,
> | as we can see by the way instance variables are designed :-)
> |
> | Similarly, it's true that a class and its objects are "related" -- but
> | that doesn't mean that any feature or even nuance of language design
> | where they behave separately has to be or should be removed.  There's
> | ample room inside class definitions to do all the things you're
> | talking about, going through conventional, "polite" channels:
> |
> |    class C
> |      def x
> |        @x ||= 10
> |      end
> |    end
>
> "Polite"? Bull-hockey. That is a hack!

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.

How would you have done it?

> 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....

>  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 -- ?

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.


David

-- 
David A. Black
dblack / wobblini.net