From: Mark Hubbart <discord@...>
Date: 2004-06-16T07:09:36+09:00
Subject: Re: undefine


On Jun 15, 2004, at 1:38 PM, Sean O'Dell wrote:

> On Tuesday 15 June 2004 11:45, Mark Hubbart wrote:
>> On Jun 15, 2004, at 10:19 AM, tony summerfelt wrote:
>>> On Tue, 15 Jun 2004 14:55:05 +0900, you wrote:
>>>>> I did not advocate removing, a.k.a. undefining,
>>>>> instance variable,
>>>
>>> it would be a local variable i'd be undefining, probably not an
>>> instance variable (although i'd like that option also)
>>
>> I think the whole point here is that it isn't Ruby-ish to rely on a
>> variable being defined or not. Ruby wassn't built to do things in that
>> way; a couple examples in this thread show how variables are
>> automagically defined when code is parsed. They aren't defined at
>> runtime, they are defined at eval time. So basically, If you are
>> translating code from Perl that undefines local variables, you will
>> have to find a different way of doing it, due to the way Ruby was
>> designed. I doubt that this is likely to change, because it's part of
>> how Ruby was designed.
>
> Actually, Matz could probably very easily expose variables as objects
> themselves to be manipulated like anything else in Ruby.  I don't think
> because he hasn't done it yet constitutes a "design decision" as much 
> as
> "something he didn't do."  It's not impossible, in other words, it's 
> just a
> feature that doesn't exist yet.

Yes, I agree, it is possible that Matz could implement that. I think 
though that it would be less of an addition than a conversion. For 
example:

   foo = 23 unless true
   p defined? foo

Will print "local-variable". The code foo in which foo was assigned to 
was not run, so the '=' operator was never really applied to it. So if 
there was a Variable class, and the '=' operator was its method, that 
method would not be called in the above code. Because of this, I 
strongly suspect the above would print "nil" if there was a Variable 
class.

I may not be understanding it fully (I'm self-taught, there are many 
gaps in my knowledge) but it *looks* like a design decision to me, and 
'variables as objects' couldn't be implemented without a non-trivial 
change to the way the language works. But I could easily be wrong :)

cheers,
Mark