Local variables & blocks

[Brian_Candler]

(guess no one read my other message on this)

I did. I'm just not really qualified to comment. But I will anyway

It always seemed strange to me that 'local variables' were not really part
of an object, and therefore seemed to break the OO model. I think what you
are proposing is to turn them into a special sort of instance variable: so

    x = 1

is a bit like

    @x = 1

except that the second case persists with the object for its entire
lifetime, whereas the first case persists only until the end of, erm, I'm
not quite sure - the current lexical scope? Perhaps then a new lexical scope
create a temporary subclass where these instance variables are deposited?
All method calls (including instances of local variables) will then follow
the normal chain of calling back up to the parent.

I'm not sure how this differs from the current situation though, if you
replace "temporary subclass" with "stack frame".

I suppose it might make local variables more widely available - for example:

class Foo
  def bar
    puts i
  end
  def baz
    i = 10
    bar
  end
end

Foo.new.baz # doesn't work now

would allow the value of 'i' to be seen in 'bar' when called from 'baz'. If
that were desirable though, I'd have thought the current implementation
could allow it (e.g. by searching through all the stack frames, not just the
current one)

Regards,

Brian.

[Tom_Sawyer]

(guess no one read my other message on this)

I did. I’m just not really qualified to comment. But I will anyway

sure you are. i really just needed some feed back to stir my own brain cells.
thanks.

It always seemed strange to me that ‘local variables’ were not really part
of an object, and therefore seemed to break the OO model. I think what you
are proposing is to turn them into a special sort of instance variable: so

x = 1

is a bit like

@x = 1

indeed, that’s exactly what bugs me too.

except that the second case persists with the object for its entire
lifetime, whereas the first case persists only until the end of, erm, I’m
not quite sure - the current lexical scope?

yes the scope

Perhaps then a new lexical
scope create a temporary subclass where these instance variables are
deposited? All method calls (including instances of local variables) will
then follow the normal chain of calling back up to the parent.

hmmm…now that gives me a notion…

I’m not sure how this differs from the current situation though, if you
replace “temporary subclass” with “stack frame”.

I suppose it might make local variables more widely available - for
example:

class Foo
def bar
puts i
end
def baz
i = 10
bar
end
end

Foo.new.baz # doesn’t work now

would allow the value of ‘i’ to be seen in ‘bar’ when called from ‘baz’. If
that were desirable though, I’d have thought the current implementation
could allow it (e.g. by searching through all the stack frames, not just
the current one)

essentially if it were seen by bar defined by baz then it would be pretty much
the same as @i. hey, perhaps we don’t need no stink’en locals

i realize now that self can’t really define the scope. b/c then any definition
would actually bind self to it . i.e.

class Foo
def bar
self #–> normally instance of Foo, but scope is Foo#bar
end
end

perhaps having an attribute of the object actually called scope would be of
interest?

class Foo
def bar
self #–> instance of Foo
scope #–> instance of Foo’s bar method
end
end

thus local variables such as:

x = 1

are in effect:

scope.x = 1

Thanks,
tom sawyer, aka transami
transami@transami.net

···

On Saturday 01 February 2003 05:59 am, Brian Candler wrote:

[Mauricio_Fernndez]

Then again, instead of calling it ‘scope’ you can call it local

local.x = 1

and then, we make some syntactic sugar:
‘local.’ <=> ‘&!@’

and we get to
&!@x = 1

OH MY GOD!

This is anyway cleaner than self[i], cause the closure only wraps one
stack frame. However it is still very powerful as it captures all
locals.

def foo
a = 1
b = 2
scope # gets all the locals
end

foo.a # 1

It would be possible to implement this in pure Ruby if we could
define a macro that used #binding .

If you go the way of adding a prefix for locals you cannot possibly beat
something like ‘&local’; moreover that notation doesn’t create
‘super-closures’. The point is it seems we have something against
adding line noise

Ummm I’m thinking of the weirdness of having instance method objects…

class Bar
def foo
end
class << foo
def bar

Now, I’m an instance method singleton method. Uh?

end
iamAlocalOfFoo = true
end
end

If everything is going to be an object, Ruby is going to be Smalltalk

···

On Sat, Feb 01, 2003 at 10:57:42PM +0900, Tom Sawyer wrote:

i realize now that self can’t really define the scope. b/c then any definition
would actually bind self to it . i.e.

class Foo
def bar
self #–> normally instance of Foo, but scope is Foo#bar
end
end

perhaps having an attribute of the object actually called scope would be of
interest?

class Foo
def bar
self #–> instance of Foo
scope #–> instance of Foo’s bar method
end
end

thus local variables such as:

x = 1

are in effect:

scope.x = 1

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

• dpkg ponders: ‘C++’ should have been called ‘D’
  – #Debian