Local variables & blocks

Sat, 1 Feb 2003 21:59:21 +0900, Brian Candler B.Candler@pobox.com pisze:

It always seemed strange to me that ‘local variables’ were not really
part of an object, and therefore seemed to break the OO model.

For me it’s a flaw of a model if it requires local variables to be
stored somewhere. Splitting an expression by putting a temporary
result in a local variable shouldn’t have any visible effect as long
as the name doesn’t clash with other names in some small scope around.

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

Foo.new.baz # doesn’t work now

And that’s good - local variables in a method should be local to the
method, so one doesn’t need to look elsewhere to avoid name clashes.

I like static scoping, and I don’t mind something resembling explicit
declarations. Actually I think every language which tries to unify
creation of a new local variable with assignment to an old variable
has confusing scoping rules:

  • Python’s scoping rules changed not so long ago: nested scopes were
    introduced, but you still can’t assign to a variable from an outer
    scope, only read it. Having an assignment anywhere in a scope
    serves for a declaration. Python doesn’t use nested functions much,
    anonymous functions are rare and ugly, so these Ruby’s problems
    aren’t problems in Python. Rule is simpler than in Ruby but it
    restricts more what you can do.

  • Perl has explicit declarations (‘my’), otherwise variables are global.
    It’s not confusing nor restricted but has a default which is bad
    for large programs.

  • Ruby treats scoping of method blocks and loop bodies differently,
    although otherwise they are very similar - this is confusing.
    I don’t like that block’s formal parameters aren’t always local.
    And I prefer to let variables introduced in blocks stay local
    to blocks. Or at least to be able to do that - but using := for
    introduction of a variable and = for assignment to an old variable
    would be backwards.

    I don’t like special-casing $_ and $~, even though it’s handy.
    They are magic, not quite local because some builtin methods
    assign to these variables existing in the scope of a function which
    called them!

What I like in Python, as opposed to Perl and Ruby: rules for binding
function names are the same as for variables, function definition is
another syntax for an assignment to function name.

Perl is broken here: functions defined in functions are global!
Even if they refer to local variables from the enclosing function!!!
‘sub f {my $x = ++$i; sub g {print “a$x\n”}} f; f; g’ prints “a1”,
with calls to f removed it prints “a”.

Ruby tries to be “pure OO” and emulates functions with methods;
their names are global and they can’t be nested. Fortunately it has
blocks, unfortunately (for syntactic and efficiency reasons) it also
has procs as a different concept.

···


__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.