# #It would require declarations, I think. Ruby is, for the most part, a #declaration-free language. This is matz choice. Instead you can tell #what a thing is by how it looks: "Class", "Module" or "Constant",
#"@@class_var", "@instance_var", "$global_var, "method" or "local_var".
# #It's probably a very good thing that globals have a visual clue. As for #the others, I sometimes think not. Yes, knowing what a thing is right #off is nice, but the perlishness is hard on the eye.
# #T.
#
k, if we cannot adjust vars,
How about creating fxn declarations that unlike methods they can see
through...
x = 1
deff fx
p x
end
fx # prints 1
But i think it's an overkill to create new decl just so one can just see
through, no?
k, if we cannot adjust vars,
How about creating fxn declarations that unlike methods they can see
through...
x = 1
deff fx
p x
end
fx # prints 1
But i think it's an overkill to create new decl just so one can just see
through, no?
I think it's overkill to create a way to make local variables not
scope-local. We already have many types of variables that can be used
in this case depending on what you're doing (including globals,
constants, arguments and instance and class variables). What is the
compelling reason to stomp on local variables? If you want to keep the
scope, create a lambda. If not, define a normal method. I don't see the
problem with that scheme as it exists.
#go go go
mfoo()
------------------------------------
If you are looking for something without all the $,@,@@,$@ etc. and implied visibilities you are looking for another language. (save the above as foo.py and try it)
Ok, i will hide quickly before getting lapidated...
Hmm... I just ran into a problem with constant lookup (namely
class/module lookup). I wrote an autoloader, such that of #const_missing it will try to find the class or module in a file and
require it. Unfortuately, for it to work I ALWAYS has to use '::'
before the class/module name. I know what the problem and how to fix
--I need to work upward through each namespace to see if it's there.
But that got me thinking about what botp has asked.
First I wondered what this could be meaningful:
foo = [ "a","b","c" ]
def mfoo
::foo.each do |f|
p f
end
mfoo
Then wondered too if variable lookup could proceed in a manner like
constant lookup. If you don't find it in the current scope, then try
the next one up, and so on. local -> instance -> class -> module
namespaces -> ... -> top/global. (hmm..That's how block scopes seem to
work too, now that I think of it.)
I must be over looking something though, it seems too straight foward
P.S. Matz, I would really like to know what you might have done if
using case sensitivity for class/module names wasn't an option. I think
that's a very interesting question.
Hmm... I just ran into a problem with constant lookup (namely
class/module lookup). I wrote an autoloader, such that of #const_missing it will try to find the class or module in a file and
require it. Unfortuately, for it to work I ALWAYS has to use '::'
before the class/module name. I know what the problem and how to fix
--I need to work upward through each namespace to see if it's there.
But that got me thinking about what botp has asked.
First I wondered what this could be meaningful:
foo = [ "a","b","c" ]
def mfoo
::foo.each do |f|
p f
end
mfoo
Then wondered too if variable lookup could proceed in a manner like
constant lookup. If you don't find it in the current scope, then try
the next one up, and so on. local -> instance -> class -> module
namespaces -> ... -> top/global. (hmm..That's how block scopes seem to
work too, now that I think of it.)
I must be over looking something though, it seems too straight foward
That would essentially do away with the notion of a local variable. I
think it's valuable to have them -- really quarantined "scratchpad"
things that just don't overlap between scopes. Writing things that
depend on local variable names from other scopes is pretty fragile.
That would essentially do away with the notion of a local variable. I
think it's valuable to have them -- really quarantined "scratchpad"
things that just don't overlap between scopes. Writing things that
depend on local variable names from other scopes is pretty fragile.
Would it? Hmm.. I guess I was thinking that if you assigned a vairable
in the current scope it would get locked into that scope, and hence be
just as local as it ever was (kind of like method vs. local var).
foo = 1
p foo
def x
foo = 2
p foo
end
x
p foo
_produces_
1
2
1
To hang on to the outerscope one would have to "replace" foo instead of
assign it. Tough I suppose that'd require a general ability to use #replace on anything (and probably a replace operator like ":=").
Nonetheless, doesn't that preserve local vars and yet "open-up" the
scopes? (Mind you I'm not neccessarily suggesting this would even be
possibile given how Ruby is implemented, but the idea in general seems
intriging.)
That would essentially do away with the notion of a local variable. I
think it's valuable to have them -- really quarantined "scratchpad"
things that just don't overlap between scopes. Writing things that
depend on local variable names from other scopes is pretty fragile.
Would it? Hmm.. I guess I was thinking that if you assigned a vairable
in the current scope it would get locked into that scope, and hence be
just as local as it ever was (kind of like method vs. local var).
foo = 1
p foo
def x
foo = 2
p foo
end
x
p foo
_produces_
1
2
1
To hang on to the outerscope one would have to "replace" foo instead of
assign it. Tough I suppose that'd require a general ability to use #replace on anything (and probably a replace operator like ":=").
Nonetheless, doesn't that preserve local vars and yet "open-up" the
scopes? (Mind you I'm not neccessarily suggesting this would even be
possibile given how Ruby is implemented, but the idea in general seems
intriging.)
It's fragile because it means you're coupling things that are in
different scopes. You might, for example, want to refactor part of
your program (put a class definition in another file, or whatever),
and you'd have to keep track of these "local" variables because
someone, somewhere, might have used your "local" variable in another
scope with ::var or whatever.
Keep in mind that with Class#new, class_eval, define_method, closures,
and other such tools, you can do a fair amount of scope-capturing
already. I think part of the point of the class and def keywords is
to seal off the scope of local variables.
It's fragile because it means you're coupling things that are in
different scopes. You might, for example, want to refactor part of
your program (put a class definition in another file, or whatever),
and you'd have to keep track of these "local" variables because
someone, somewhere, might have used your "local" variable in another
scope with ::var or whatever.
True. But wouldn't you be facing the same thing by using Const, $var,
or @@var? Nonethless you make it clear that good coding practices, like
SOC, is the way to go.
Keep in mind that with Class#new, class_eval, define_method, closures,
and other such tools, you can do a fair amount of scope-capturing
already. I think part of the point of the class and def keywords is
to seal off the scope of local variables.
It's fragile because it means you're coupling things that are in
different scopes. You might, for example, want to refactor part of
your program (put a class definition in another file, or whatever),
and you'd have to keep track of these "local" variables because
someone, somewhere, might have used your "local" variable in another
scope with ::var or whatever.
True. But wouldn't you be facing the same thing by using Const, $var,
or @@var? Nonethless you make it clear that good coding practices, like
SOC, is the way to go.
Keep in mind that with Class#new, class_eval, define_method, closures,
and other such tools, you can do a fair amount of scope-capturing
already. I think part of the point of the class and def keywords is
to seal off the scope of local variables.
And thus enforcing good coding practices?
I think it at least provides an environment conducive to good
practices.
