From: Glenn Parker <glenn.parker@...>
Date: 2005-04-09T00:43:32+09:00
Subject: Re: Seven new VMs, all in a row

Avi Bryant wrote:
> Glenn Parker wrote:
>>Avi Bryant wrote:
>>>Not exactly as Ruby does, but you can simply add new instance variables
>>>to the class definition whenever you compile a method that uses a new
>>>one.
>>
>>Isn't that jumping the gun just a bit?  An instance variable (in Ruby)
>>should not exist in an object until the line that assigns/creates it is
>>actually executed.  It's a subtle point, but it could impact some types
>>of reflective programming.  Maybe you can mask its existence somehow?
> 
> Yes, pretty easily I'd think.  For example: when you create a new
> instance in Smalltalk, all the instance variables start out initialized
> to Smalltalk's nil value (of class UndefinedObject).  As soon as it was
> referenced or assigned to, that would get replaced with some Ruby value
> (possibly Ruby's nil, of class NilClass).  So you could always tell for
> a given instance which instance variables already "exist" inside the
> Ruby semantics.
> 
> You could also just use a hashtable for each instance to hold all of
> the variables, like Ruby does, but the fact that Smalltalk can do
> direct instance variable access ends up being a nice speed and memory
> gain, so I'd rather not give that up.

The Smalltalk Ruby will still need to handle more dynamic methods of 
instance variable creation:

class MyClass
   def add_ivar(name)
     instance_variable_set(name, nil)
   end
end

What happens to instances that have already been created when a new 
instance variable is seen by the compiler?

There are also issues with using more memory than necessary if the 
interpreter creates every instance variable the moment it is observed by 
the compiler.

I'm guessing Ruby instance variables will have to be created dynamically.

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