From: Sean O'Dell <sean@...>
Date: 2004-06-16T07:17:58+09:00
Subject: Re: undefine

On Tuesday 15 June 2004 15:09, Mark Hubbart wrote:
> 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 :)

I looked at the BLOCK structure that is the C representation of the binding 
object, but I only learned two things.  One, I can't really tell without 
spending a lot more time poking around how dyna_vars really binds a 
symbolically named internal variable to an object and two, you probably could 
create internal variable objects to represent them.  I don't see why not.

Probably it would work best through the Binding object itself.  Matz, or 
someone who understands how the BLOCK structure is used well enough, could 
add methods to Binding to add and remove variables, and if a Variable class 
were written to point into the variable it represents in a BLOCK structure, 
it could probably also return objects to represent the variable.

	Sean O'Dell