From: "trans.  (T. Onoma)" <transami@...>
Date: 2005-01-18T00:50:12+09:00
Subject: Re: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod

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! 

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:

  def x
    10
  end

Is this "10" in the in the jurisdiction of the class or the object?

T.