Why we will use obj$func() often

[Michael Geary]

David MacQuigg wrote:
> How about instead of decorating variables with special
> symbols or capitalization, we have a rule that says any
> variables with unusual scope must be declared in a
> statement at the top of the function where they are used.
> So for example
>
> def func( x, y ):
>    global   a, b, c    ### module level
>    external d, e, f    ### one level up
>    ...
>
> This would avoid the need for new and unique symbols,
> would unclutter the code in the body of the function, would
> provide a single place where you could see the scope of any
> unusual variable, and would answer the question "What
> external dependencies does this function have?"  Does it
> satisfy the need you are seeing for & variables?

Hey, that is a great idea, David. I definitely like it better than the &
notation. It would work in Python as well as Prothon, and give me clean and
readable closures like I have in JavaScript.

I would want it to mean:

    external d, e, f   # # # search up the scope chain

because I often want to use variables from scopes more than one level up.
And maybe another word would be better than 'external' (although I don't
have one in mind). But the idea is terrific.

> Python added "read access" to external variables, so they
> must have considered "write access" as well.  I don't know
> the history, but I would guess the reason they didn't allow
> this is the same as the reason they don't allow GOTO.  Yes
> it is powerful, but it might encourage bad programming.

We're both speculating, of course, but my guess is simply that automatic
creation of variables by assignment conflicts with writing to variables from
outer scopes. The global statement solves this for global variables, but no
one thought it important enough to do something for nested scopes as well.
Just my guess.

> Can you imagine having to debug a large program where
> none of the functions have any arguments, just &vars buried
> in the bodies of the functions?  That is the kind of code that
> might be written by someone who does not want to think
> ahead.  You can write the call() first, then use & variables
> whenever you need an argument.  These are the kind of
> things that must be considered when looking at a new
> feature for a language.

In JavaScript, I often use nested functions to factor out common operations
within a function--things that are done repeatedly inside that function but
aren't of interest outside the function. Lexical scoping lets me do that
without the nuisance of passing in the same arguments to all these nested
functions, or creating some little object for that purpose. I could post
some sample code if anyone wants, but I fear I may have posted too much
JavaScript code here already. :-) But the point is that I use this very
thing to make my code simpler and more readable.

-Mike