From: "David A. Black" <dblack@...>
Date: 2005-01-18T00:30:27+09:00
Subject: Re: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod

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

etc.


David

-- 
David A. Black
dblack@wobblini.net