Mark Bush wrote:
> Robert Klemme wrote:
>> Plus, what would you do in this case?
>> 
>> a=[SomeClass.new]
> 
> Actually, in this case it's not so bad.  The variable "a" refers to the 
> array (so you're not interested in the array contents) so you can use 
> similar methods on local variables to get it's name, then do:
> 
> eval var
> 
> on each local variable to see if the object returned is your original 
> one, just not easily in a method as local variables are now in a 
> different scope, albeit the scope of the caller (and being very, very 
> careful about exceptions and side effects).  What really made me cringe 
> was:
> 
> a = nil

Since nil is an instance of NilClass, I suppose 
MyProposedSystemHook(nil) would return [:a,...any other variable 
_assigned_ to nil]

><I agree 100% though that the real issue here is that Jeff wants the name 
> of an object to be an attribute

No! (unless you meant Kernel attribute, which it already is, at least 
indirectly). The symbol name cannot belong to the object because rvalues 
can not know about lvalues at instantiation. Howeevr, the kernel owns 
both and so can manage associations between them!
-- 
Posted via http://www.ruby-forum.com/.