[suby-ruby] Your all time desired fundemental Ruby mod

ruby-talk
81

You want it not to inherit? Do you mean the value of @background or the actual
method #background? Right now method gets inherited but not the value --you
can change the value on a per class bases. But if you did not want the method
inherited... I'm not sure. Guess you could use a module.

Hmm... I wonder how all the variations might be satisfiable... I wonder if
using something like 'inherit' and 'do_not_inherit', like private and public,
might not clear all that up. Eg.

  class A
    do_not_inherit
    def self.background
      #...
    end

    inherit
    def repaint
      #...
    end
  end

T.

···

On Tuesday 18 January 2005 01:51 am, Martin DeMello wrote:

"trans. (T. Onoma)" <transami@runbox.com> wrote:
> BTW I personally like your style: Button.@background :wink:
>
:slight_smile:
:
> Try:
>
> class Button
> class < self
> def background
> @background ||= BLUE
> end
> end
>
> def repaint
> @background = self.class.background
> ...
> end
> end
>
> class ImageButton < Button
> end
>
> That's the idea. Work for you?

No, becaus the idea is that ImageButton will *not* inherit @background
from Button, it being a separate object.

82

Yukihiro Matsumoto wrote:

Initializing module instance variables are one of the things I want to
fix. But I'm not sure what is the best way to fix. Maybe AOP-like
hooks is the way to go. I'm waiting the conviction to come.

It's not pretty, probably because the idea is based on Perl experience:

module MM
   def x
     @x_value ||= 100
     redefine_x
     x
   end

   def x=(xx)
     @x_value = xx
   end

   private

   def redefine_x
     class << self
       def x
         @x_value += 1
       end
     end
   end
end

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

83

Yukihiro Matsumoto wrote:

Initializing module instance variables are one of the things I want

to

fix. But I'm not sure what is the best way to fix. Maybe AOP-like
hooks is the way to go. I'm waiting the conviction to come.

While AOP-like hooks can do the job, I think they are a too heavy for
the task. Nontheless.... I'm not one to promote the use of :pre, :post
and :wrap. As you know. I've pointed out potential snags with their use
in the past, but I'll go ahead and suggest this possibility:

module M
def initialize:super
# super is implicitly called here
@var = 10 #set an instance var
# initialize is now implicitly called here
end
end

On the other hand, why get so fancy about it? A dedicated appraoch is
really more appropriate --since the matter is simply one of defining a
default instance value:

  module M
    instance "@var", 10

T.

84

def self.initialize
  ...
end

?

···

On Jan 17, 2005, at 3:37 PM, Yukihiro Matsumoto wrote:

Initializing module instance variables are one of the things I want to
fix. But I'm not sure what is the best way to fix. Maybe AOP-like
hooks is the way to go. I'm waiting the conviction to come.

85

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

···

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 :slight_smile: 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 :slight_smile:

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

86

No, I want it to inherit, and I specifically want both Class.@background
variables to point to the same object at all times. Possible with
@@variables (though I'd forgotten about the order-of-creation effect
Joel pointed out, so I'm indeed better off using a SuperHash).

martin

···

"trans. (T. Onoma)" <transami@runbox.com> wrote:

> > class Button
> > class < self
> > def background
> > @background ||= BLUE
> > end
> > end
> >
> > def repaint
> > @background = self.class.background
> > ...
> > end
> > end
> >
> > class ImageButton < Button
> > end
> >
> > That's the idea. Work for you?
>
> No, becaus the idea is that ImageButton will *not* inherit @background
> from Button, it being a separate object.

You want it not to inherit?

87

Yikes! I have developed an email stutter :wink:

···

On Monday 17 January 2005 10:50 am, trans. (T. Onoma) wrote:

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

88

Hi --

> Hi --
>
> > > Yes :slight_smile: 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 :slight_smile:
>
> 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 :slight_smile: 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

···

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

On Monday 17 January 2005 10:30 am, David A. Black wrote:
> On Mon, 17 Jan 2005, trans. (T. Onoma) wrote:
> > On Monday 17 January 2005 09:21 am, David A. Black wrote:

--
David A. Black
dblack@wobblini.net

89

Okay. In that case you can use a constant.

class Button
Background = [BLUE]
def self.background
Background[0]
end
def self.background=(b)
Background[0] = b
end
....

It would be nice if the constant did not need to be an array. Hmmm...
You know, maybe we should give that constant warning crud the boot. I
mean this is RUBY! This is DYNAMIC stuff! What's a "pretend static"
doing in such a world as this?

T.

90

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

···

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

91

David A. Black wrote:

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

While I have not followed the whole discussion the above can be quite a burden when you're writing lots of methods that use the same instance variables that may not yet by initialized. In that case you will have to call a method ensure_initialized() or similar that sets all instance variables to default values if they were not yet set and call that from every other method.

I don't know if there is a better way, but I'd certainly like to have one...

92

trans. wrote:

Okay. In that case you can use a constant.

class Button
Background = [BLUE]
def self.background
Background[0]
end
def self.background=(b)
Background[0] = b
end
....

class RadioButton < Button
   # ...
   self.background = RED
end

p Button.background # ==> RED

The change went up the inheritance tree. Is this what you wanted? (Maybe it is, and I didn't follow the discussion up to this point...)

93

Hi --

···

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

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.

I think we have to agree on a parting of the ways on this at this
point :slight_smile:

David

--
David A. Black
dblack@wobblini.net

94

That is what I wanted, but now my head hurts trying to figure out why it
works :slight_smile: Isn't RadioButton a separate object from Button, and as such
shouldn't it have its own copy of all instance variables?

martin

···

Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

class RadioButton < Button
   # ...
   self.background = RED
end

p Button.background # ==> RED

The change went up the inheritance tree. Is this what you wanted? (Maybe
it is, and I didn't follow the discussion up to this point...)

95

Okay. But that's too bad I think. I'd really like to get more to the bottom of
this.

I do find it strange that you seem not think it is impolite that a module or
superclass should be able to define an instance var. Is this because a
subclass should have the right to not allow that instance var to be defined?
If that's the case then maybe that's right. I'm not sure if its a real
problem. On the other hand modules aren't superclasses, as mixins, I think
modules need that right (IMHO).

Thanks for the discussion,
T.

···

On Monday 17 January 2005 12:11 pm, David A. Black wrote:

I think we have to agree on a parting of the ways on this at this
point :slight_smile:

96

Martin DeMello wrote:

···

Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

class RadioButton < Button
  # ...
  self.background = RED
end

p Button.background # ==> RED

The change went up the inheritance tree. Is this what you wanted? (Maybe it is, and I didn't follow the discussion up to this point...)

That is what I wanted, but now my head hurts trying to figure out why it
works :slight_smile: Isn't RadioButton a separate object from Button, and as such
shouldn't it have its own copy of all instance variables?

I snipped too much... the storage for #background was a constant called BACKGROUND (or something) whose value was an array of the form [RED], so that binding would be inherited from Button to RadioButton.