Replying to multiple posts:
On Oct 31, 5:19 pm, Stefan L. [email protected]
A def inside a method definition defines a method in
self’s class. It is not local to the enclosing method definition.
Wow, I did not realize that. That changes my thinking a lot.
Then why the first-class code blocks? Certainly makes Ruby a
functional language, if only for blocks.
Yes, Ruby has a good deal of functional features and they
fit in very nicely with the current scoping rules.
Although I’m not sure what you mean with “first class” code
blocks. The block syntax is actually tied to message passing.
Well, blocks aren’t first class per-se, but they can easily be turned
into first-class procs.
and module instance variables suffice. OTOH, you can nest
blocks as much as you like and scoping is what you expect.
I recognize that access to nonlocal vars can be simulated with
instance variables. It does seem weird to allow two different
paradigms that interact with each other in a confusing - or at the
least non-trivial - matter (just look at my confusion).
I guess my big beef with Ruby is that it is too complex and bloated
with features that often are inconsistent or lack symmetry with each
other. It’s too “magical”, making it hard to learn exactly how the
language works. From a language design perspective, Ruby really seems
like a mess to me, although with moments of brilliance. Most of the
time, when I’m metaprogramming, I’m guessing and looking at the
output, hoping I got so-and-so quirk correct.
Actually, I think this all could be mitigated to a certain extent if
the documentation for Ruby were improved. I could not find an official
language reference besides the API documentation, which is not
sufficient by itself. Obviously it did not contain much information on
scoping or non-API language features.
On Oct 31, 5:43 pm, Mike G. [email protected] wrote:
define_method| besides this block issue. Compare:
The break in symmetry is intentional because it prevents local variables
from willy-nilly infecting your methods, which you agreed is a good
I agreed in the sense that without extra syntax, it would be fragile,
but as my example pointed out, it doesn’t necessarily have to be
But then you’ve missed out on the advantage of lexical local variables.
What you propose takes the “lexical” out of “lexical scope”. It is just
nested variables which are visible from other scopes.
No, what I am proposing is a mechanism for lexical scope. This is what
I mean with that |scope.x| - treat x as if it were from an enclosing
Except I do NOT want x to be globally accessible. I just want to to be
accessible be child scopes. If I wanted it to be globally accessible,
then I would just use global variables.
So don’t make it global, as in the Top example above.
But they are not local variables. Local vars for a function are
created each time the function is called. Having access to those local
vars outside of the function makes no sense at all.
On Nov 1, 12:40 am, “ara.t.howard” [email protected] wrote:
does what you’d expect it do.
define_method :method_missing do |_|
cfp:~ > ruby a.rb
That’s, um, interesting. Less efficient than I hoped, but then again
Ruby is not known for its efficiency. Though that method_missing does
give me an idea…