FEATURE REQUEST: 'my' local variables 
Author Message
 FEATURE REQUEST: 'my' local variables

Ruby is, indeed, a very well designed language.
But here is one aspect of Ruby's scoping rules which might be worth of some
improvement.

At present (Ruby-1.6.2) the Ruby scoping rules stipulate that inside a block
(either {...} or do...end) a new local variable is created _ONLY_ if _NO_ such a
variable of the same name exists in any of the enclosing scopes. On the other
hand if there is already such a varible in an enclosing scope it will used in
the inner block instead of creating a new variable.  This rule is very
convenient in many cases.  For example:

x = 1
{
  x = 7 # the 'x' binding is reused from the outer scope
  y = 0 # new variable 'y' (local to this block) created

Quote:
}

x  # -> 7
y # raise NameError: undefined local variable

On the other hand in some cases one wants to be able to create a local variable
in the inner block even though a variable with the same name already exists in
one of the enclosing scopes.

# PROPOSED FEATURE:
x = 0  #line_1
{
  my x = 7  # new varible 'x' shadowing 'x' from line_1
  x  # -> 7

Quote:
}

x    # -> 0

I guess it should not be hard to add this functionality to the language.
Any thoughts?

Thanks,
--Leo <slonika at yahoo dot com>



Sun, 24 Aug 2003 11:32:58 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:

> # PROPOSED FEATURE:
> x = 0  #line_1
> {
>   my x = 7  # new varible 'x' shadowing 'x' from line_1
>   x  # -> 7
> }
> x    # -> 0

This seems to me like it would be very useful.

Cullen J O'Neill
--



Sun, 24 Aug 2003 12:54:05 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:

># PROPOSED FEATURE:
>x = 0  #line_1
>{
>  my x = 7  # new varible 'x' shadowing 'x' from line_1
>  x  # -> 7
>}
>x    # -> 0

If I know that x should be local, I would
probably just name it x2 instead. Of course, I
try to avoid names like 'x' anyway, but you get
the idea.

I'm not too fond of the way the language
currently works (sometimes it does *this*, but
other times it does *that*). But I know it would
break too much code to change now.

Bottom line: Although creative and reasonable, I
don't see this suggestion as improving the
language.

Kevin



Sun, 24 Aug 2003 12:46:13 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:

> Ruby is, indeed, a very well designed language.
> But here is one aspect of Ruby's scoping rules which might be worth of some
> improvement.
> ...

This same request was brought up by Ben Tilly not too long ago.
(Posted as #U006 at http://www.rubygarden.org/ruby?NeedDiscussion)

Furthermore, a very long thread was conducted last Oct.
You can find the 'restart' at  [ruby-talk:5552]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/5552

Quote:

> # PROPOSED FEATURE:
> x = 0  #line_1
> {
>   my x = 7  # new varible 'x' shadowing 'x' from line_1
>   x  # -> 7
> }
> x    # -> 0

> I guess it should not be hard to add this functionality to the language.
> Any thoughts?

My first thought is, of course, this has been brought up already.

My second thought is that, yes, something probably needs to be done.

My third thought is, please don't use 'my' to implement this.
For one thing, what was tacked on in Perl is not likely to be
the best way for Ruby to handle it. Not to mention that x is already
a local variable. Of course, the problem is that Ruby might seem
to have to be tacking something on in any case.  Ruby will
have to either create a new kind of scope, or nesting, or naming.

This particular nuance of scoping in Ruby is hard to grasp...
I am not sure there will be an answer any time soon.

This is perhaps a good place to expose some of the complexity of Ruby.

By the way, blocks don't work in Ruby the same as they do in Perl.

In any case, since the October thread, I have come to actually like
the way things are. I haven't ever had to worry about previously
named variables. In fact, all this worry about overlapping scope
seems so far-fetched to me now. In practice, there is hardly ever
any need to maintain such large numbers of local vars that might
conflict because 1) it is easy to modularize Ruby code, 2) it
is easy to protect namespaces, and 3) it is easy to modularize Ruby
code. (I may be repeating myself).

So apart from the fact that I spent so many hours trying to figure it all
out back then, I haven't had much to worry about now that I grasp it better.
I have just seen too many other areas where it seems to make up for
the inconvenience of having to initialize in advance and otherwise control
the namespace.

I do think it would be interesting to have some kind of class that allowed
you to create 'shadowed' variables, though...

Guy N. Hurst

--
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            (757)623-9688 FAX 623-0433
PHP/MySQL - Ruby/Perl - HTML/Javascript



Sun, 24 Aug 2003 12:56:21 GMT  
 FEATURE REQUEST: 'my' local variables
At 06 Mar 2001 19:32:58 -0800,

Quote:

> # PROPOSED FEATURE:
> x = 0  #line_1
> {
>   my x = 7  # new varible 'x' shadowing 'x' from line_1
>   x  # -> 7
> }
> x    # -> 0

CLU ((<URL:http://www.pmg.lcs.mit.edu/CLU.html>)) has explicit
variable declarations and nested scopes, but prohibit the
shadowing of variables in outer scopes.
I think this rule is effective to avoid bugs.

Shugo



Sun, 24 Aug 2003 14:24:58 GMT  
 FEATURE REQUEST: 'my' local variables

L> {
L>   my x = 7  # new varible 'x' shadowing 'x' from line_1
     ^^
     ||

 Please, no. Why make the same error of perl with this very strange name ?

Guy Decoux



Sun, 24 Aug 2003 14:38:36 GMT  
 FEATURE REQUEST: 'my' local variables
If you want to use this sort of idiom, try this example which doesn't
require any changes to the language:

require 'context' #See below...
x = 0
{
  my = Context.new
  my.x = 7
  my.x #-> 7

Quote:
}

x #-> 0

Here's the code for Context (suggestions welcome, I'm sure there are better
ways to do this). You can probably use something like this to suit your
needs. Also, if you want immutable names, do this:

my = Context.new(false)
my.x = 2
my.x # -> 2
my.x = 5 #-> RuntimeError: Can't reassign variable

#context.rb
class Context

    def X

    end

      def X=(val)

      end
    else
      def X=(val)
        raise RuntimeError, "Can't reassign variable"
      end
    end
  }

  def initialize(mutable = true)


  end

  def method_missing(sym, *args)
    attrib = sym.to_s
    if attrib[-1,1] != "="
      raise NameError, "undefined method '#{attrib}' for object #{to_s}"
    end
    prop_name = attrib[0, (attrib.length - 1)]

    instance_eval(new_meth_def)

  end  
end    

Hope that helps,

Bryn

Quote:
-----Original Message-----


Sent: Tuesday, March 06, 2001 9:10 PM

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


> # PROPOSED FEATURE:
> x = 0  #line_1
> {
>   my x = 7  # new varible 'x' shadowing 'x' from line_1
>   x  # -> 7
> }
> x    # -> 0

This seems to me like it would be very useful.

Cullen J O'Neill
--




Sun, 24 Aug 2003 15:07:23 GMT  
 FEATURE REQUEST: 'my' local variables


#
# L> {
# L>   my x = 7  # new varible 'x' shadowing 'x' from line_1
#      ^^
#      ||
#
#  Please, no. Why make the same error of perl with this very strange
#  name ?

And why make the same error as Perl by distinguishing the shadow case
versus the non-shadow case? (Or so it seems to me, because
I was always writing my, my, my all the time in Perl.)

So why not this half-baked partly off-the-wall idea:

  [...]
  {
    x = 7       # New variable 'x' shadowing previous 'x'.
    prior x = 8 # Changing previously existing variable 'x'.
  [...]

Maybe
   'ext' -- for external to local scope
   'prev' -- for previous scope
   'enc' -- for enclosing scope
   'outer' -- for outer scope
would be better than 'prior'.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)



Sun, 24 Aug 2003 15:07:05 GMT  
 FEATURE REQUEST: 'my' local variables

C>   [...]
C>   {
C>     x = 7       # New variable 'x' shadowing previous 'x'.
C>     prior x = 8 # Changing previously existing variable 'x'.
C>   [...]

C> Maybe
C>    'ext' -- for external to local scope
C>    'prev' -- for previous scope
C>    'enc' -- for enclosing scope
C>    'outer' -- for outer scope
C> would be better than 'prior'.

 This was my 2nd objection :-)

 How many script do you break with your new keywords 'ext', 'prev',
 'prior', etc

pigeon% ruby
def prior x
   p x
end

prior x = 8
^D
8
pigeon%

Guy Decoux



Sun, 24 Aug 2003 15:15:54 GMT  
 FEATURE REQUEST: 'my' local variables
In message "[ruby-talk:12204] FEATURE REQUEST: 'my' local variables"

Quote:
># PROPOSED FEATURE:
>x = 0  #line_1
>{
>  my x = 7  # new varible 'x' shadowing 'x' from line_1
>  x  # -> 7
>}
>x    # -> 0

>I guess it should not be hard to add this functionality to the language.
>Any thoughts?

"my" seems too complex for user.

But I think some shadowing mechanism for an instance variable is
helpful because we have to choose carefully name of an instance
variable when we define a subclass with new features.  If name
collision is occur, the super class's functions would not work.

-- Gotoken



Sun, 24 Aug 2003 15:13:37 GMT  
 FEATURE REQUEST: 'my' local variables


Quote:
> On the other hand in some cases one wants to be able to create a
local variable
> in the inner block even though a variable with the same name already
exists in
> one of the enclosing scopes.

> # PROPOSED FEATURE:
> x = 0  #line_1
> {
>   my x = 7  # new varible 'x' shadowing 'x' from line_1
>   x  # -> 7
> }
> x    # -> 0

> I guess it should not be hard to add this functionality to the
language.
> Any thoughts?

I don't find that an improvement. On the contrary. To me it seems like
a bad excuse for the ability of bad naming. It's error and bug prone.
It's not very intention revealing and slows down readability
significantly.

If you absolutely must,  then I find Bryn's suggestion in
[ruby-talk:12214] a decent compromise.

Dennis Decker Jensen



Sun, 24 Aug 2003 17:38:05 GMT  
 FEATURE REQUEST: 'my' local variables
    GK> In message "[ruby-talk:12204] FEATURE REQUEST: 'my' local variables"

    >> # PROPOSED FEATURE:
    >> x = 0  #line_1
    >> {
    >> my x = 7  # new varible 'x' shadowing 'x' from line_1
    >> x  # -> 7
    >> }
    >> x    # -> 0
    >>
    >>
    >> I guess it should not be hard to add this functionality to the language.
    >> Any thoughts?

    GK> "my" seems too complex for user.

I do not understand why "my" is too complex to a user. It has been in Perl for
years and no one complained of its complexity. Similar semantics exists in
Scheme and Lisp (let (...)) and has been in use for decades .
If you do not like token "my" it can be any other name like "local", etc.
Bottom line, Ruby does not have a mechanism to push an arbitrary
local variable onto its local scope. And this is bad!

-- Leo [slonika AT yahoo DOT com]



Mon, 25 Aug 2003 06:11:44 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:

>Bottom line, Ruby does not have a mechanism to push an arbitrary
>local variable onto its local scope. And this is bad!

Why is it bad Leo?

Right now I cannot see how Ruby would be improved by this change.

Just because we could do it, we need to ask the question why first. Any
answers of the form "because 10 million lemmings cannot be wrong" are
not really answering the question. What problems are solved in Ruby by
making this change?

Personally I can see many potential errors that developers could make if
this kind of local variable were to be introduced. It's really easy to
confuse a local with a global.

Pete
----
Pete McBreen, McBreen.Consulting , Cochrane, AB

Software development is meant to be fun,
     if it isn't the process is wrong



Mon, 25 Aug 2003 06:42:03 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:
>>>>> On Wed, 7 Mar 2001 16:07:05 +0900,


cs>   [...]
cs>   {
cs>     x = 7       # New variable 'x' shadowing previous 'x'.
cs>     prior x = 8 # Changing previously existing variable 'x'.
cs>   [...]

sounds kinda like `upvar' in tcl.

--
Amos



Mon, 25 Aug 2003 09:12:17 GMT  
 
 [ 83 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 

1. FEATURE REQUEST: 'my' local variables

2. Feature request: 'apply' command

3. 'local' to trap undeclared variables

4. local variables don't cause side effects

5. Global, local variables in SubVI's

6. Q: `loop' and local variables

7. un-'upvar'ing/un-'global'ing variables

8. local variable and local variable in block behave differently

9. Icons missing in 'Local' mode

10. ``vars'' declarations local to a procedure

11. Feature or Bug (F90 advance='no')

12. 'select all' feature in TK

 

 
Powered by phpBB® Forum Software