though it would not be backwards compatilble, yet it has some merit i think,
say if block using { } defined a new scope and those using do end did not?
–just an aside thought.
i can’t help but feel that this whole problem is so thorny b/c there’s some
fundemental assumptions that have been made in Ruby that at this point make
it hard to get past with out some sort of hack, whatever it may be.
it may be beneficial to step back and look at this. for starters i have always
felt a bit odd about the distinction between methods and variables:
def bar() 4 end
puts bar
vs.
bar = 4
puts bar
the use of bar after definition is ISOMORPHIC. the only exception being when
both froms are used, thus self becomes required to get to the method (the
infamous ambiguity)
likewise Procs being distinct from methods adds fruther to the layers of
complexity. i have often thought that doing:
class Foo
bar = Proc { 4 }
end
or prefereably without the Proc (such that { } meant Proc inheritly)
class Foo
bar = { 4 }
end
would make for a reasonable means of defining a method, equiv. to
class Foo
def bar
4
end
end
(hence i never liked the #call method) but anyhow, what’s this to do with
local scope? well, the “pure” idea of a scope is to shelter the inner-context
from the outer-context. thus generally, no outer definition should get in,
and all such out-definitions that one might want inside an inner-scope would
have to be passed in.
bar = 4
non = { |bar| bar + 1} # hey, these are not the same bar
puts non(bar) # bar ain't getting in unless passed.
the only “pure OO” way to get around this would be to offer an object
reference to the previous scope.
bar = 4
non = { last_scope.bar + 1} # now they the same
puts non
some sytatical suger might help: non = { &bar + 1 }
but the lack of distiction between method and variable make it clearer, i
think, where scopes are coming from. normally with,
class Foo
def bar() 4 end
def non() bar end
end
defines only a partial scope, if we wrote:
class Foo
bar = { 4 }
non = { bar }
end
we might actually consider if bar should actually be seen at all in non, but
this would lead to a lot of the above & use. imagine having to write:
class Foo
def bar() 4 end
def non() &bar end
end
so, we end up in a fight between what’s visible everywhere throughout the
scope of an object, sort of like object localized globals, and what’s truly
local to blocks and methods. that’s really the bottom line.
what syntax do you use to draw that line?
-transami
p.s. though i know that taking greater advatage of isomprophism with variables
and methods is quite a departure from today’s Ruby, i none the less think it
one to think carefully about and would like to hear what others think of it
and how it might effect the language over all.
···
On Sunday 02 February 2003 09:11 am, ahoward wrote:
how about some simple means on introducing a local scope? a new
keyword/method? perhaps ‘scope/end’ and ‘{{/}}’. this could allow the
programmer to work as wished, added to your current plan one would end up
with
…
maybe that syntax is no good, but what would be the problem of allowing
programmers to introduce scopes (most languages do)? this would allow to
the introduce your new plan, and in cases (like threads) or for people
where it might be an imperfect fit you could say ‘just introduce a scope
and it will be as before’. i guess one could simply use guy’s ‘local’
method, but it would be nice if that were built in for people who like
scopes. using this, the default for thread might be to introduce a new
scope - there are some cases where POLS means blocks should start a new
scope.
–
tom sawyer, aka transami
transami@transami.net
