[ruby-talk:12597] Re: FEATURE REQUEST: 'my' local variables

> From: Stephen White [mailto:[e-mail]]
[...]
> > The one is allowing explicit declaration of block local variables.
> > <a,b|c,d> is one choice of notations.
> 
> One problem I can see with this is that it will make code harder to
> modify. If I change the contents of a block, I will have to remember
> to "declare" my usage in the <>'s. I kinda liked not having to define
> my variables before using them.

I agree ...

> 
> > The other notation candidates may be special block form({{}}),
> 
> I already find the difference between do..end and {} to be confusingly
> similar. One block type would be nicer, especially if it could remove
> the difference between Proc objects and Method objects.
> 
> > and special declarative assignment.

I very much like the idea of special declarative assignments - this
idea might be useful to resolve other similar problems and strikes me
as very clean ...

> 
> This could be handled with a naming convention, and fits in with the
> current design of Ruby...
> 
>   :name  is global in scope
>   $name  is global in scope
>   @@name is class in scope
>   @name  is instance in scope
>   _name  is block in scope

This proposal will not go well at all with people (like me) who like 
__var_names(__).

> 
> However, I'm not so sure this is the way to go either.
> 
> > The other idea is implicit propagation of variable scope, that is
> 
> In other words, a flattening of scope. I like this idea as it aligns
> with not having nested methods. Eg, you can't do this:
> 
>   def method1
>     def method1a
>     end
>     def method1b
>     end
>   end
>   def method2
>   end
> 
> I used nested procedures all the time when I was programming in Pascal
> and found it very useful at the time. However, it has its problems and I
> think things are better without them.

Actually Ruby nested variables and more generally nested methods 
are infinitely more powerful - there is no point of sacrificing their 
power without any clear benefit - what exactly are the problems you are  
talking about? (besides that they can be used to shoot oneself in the
foot but this possibility lurks almost everywhere in Ruby.)
In general any proposal should keep in mind that methods can be 
self-altering in terms of arity, instance variable used and execution
code it self.

> 
> The same argument applies to nested variables in that they're useful, but
> things are probably better without them.
> 
> 
> 
> *** start of loony tunes proposal ***
> 
> I would like to suggest that scoping rules be removed from do..end blocks
> and stricter scoping rules be introduced for {} blocks.

I like this idea to a certain extend 
[...]
 
> it makes much more sense to define the interpreter perform a call when
> interpreting the code... in other words
> 
>   a      # will silently call a.exec

This is not workable - Method and Prog objects are objects NOT
methods - you what virtually lose all the benefits that you get 
that you can manipulated them like ordinary objects without ever
calling them.
The only way such a  proposal could work would be by cooking
up some complicated scanning rules which would soon collapse 
under its own weight ...  Ruby's scanning rules are already
quite complicated - no need to add additional complexities.

[scanning - rule
proposal cut] 

Christoph