[#16113] Strange idea... exporting from a scope — "Hal E. Fulton" <hal9000@...>

Hello...

33 messages 2001/06/01

[#16364] Re: Garbage Collection? — Michael Davis <mdavis@...>

Windows 2000 and linux (RedHat 6.2). I have run these tests on both OSs.

12 messages 2001/06/09

[#16400] Symbolic Computation III — Mathieu Bouchard <matju@...>

14 messages 2001/06/11

[#16502] Playing with Ruby Syntax (was: Initial thoughts about Ruby From a Smalltalk Programmer) — jweirich@...

Michael> Hi Everyone, I have to say I'm utterly fascinated by Ruby

9 messages 2001/06/15

[#16661] Problem running irb with Ruby 1.6.4 under FreeBSD 4.0 — Bob Alexander <balexander@...>

I've installed Ruby 1.6.4 on a FreeBSD 4.0 machine, and get the

11 messages 2001/06/20

[#16686] opening db files made by apache dbmmanage — Fritz Heinrichmeyer <fritz.heinrichmeyer@...>

14 messages 2001/06/21

[#16801] rb_define_class() vs Class.new() — Kero van Gelder <kero@...4050.upc-d.chello.nl>

Hi,

18 messages 2001/06/23
[#16802] Re: rb_define_class() vs Class.new() — ts <decoux@...> 2001/06/23

>>>>> "K" == Kero van Gelder <kero@d4050.upc-d.chello.nl> writes:

[#16841] RE: national characters is strings — "Aleksei Guzev" <aleksei.guzev@...>

Next week I'll try to rebuild Ruby with Unicode strings. But it would be

15 messages 2001/06/25
[#16842] Re: national characters is strings — matz@... (Yukihiro Matsumoto) 2001/06/25

Hi,

[#16843] Re: national characters is strings — "Aleksei Guzev" <aleksei.guzev@...> 2001/06/25

That's good enough. But I'm afraid this could ( not would ) cause string

[#16868] Something strange with Ruby's inheritance mechanism — Eric Jacoboni <jaco@...>

As Ruby beginner, i try some "canonical" OO scripts. Doing so, I've

14 messages 2001/06/25
[#16873] RE: Something strange with Ruby's inheritance mechanism — "Aleksei Guzev" <aleksei.guzev@...> 2001/06/26

[#16879] Re: Something strange with Ruby's inheritance mechanism — Mathieu Bouchard <matju@...> 2001/06/26

On Tue, 26 Jun 2001, Aleksei Guzev wrote:

[#16869] Something strange with Ruby's inheritance mechanism — Eric Jacoboni <jaco@...>

As Ruby beginner, i try some "canonical" OO scripts. Doing so, I've

12 messages 2001/06/25

[#16881] — "Aleksei Guzev" <aleksei.guzev@...>

32 messages 2001/06/26
[#16916] Re: Method overloading (option) Was: Re: — "Wayne Blair" <wayne.blair@...> 2001/06/26

[#16920] Re: Method overloading (option) Was: Re: — matz@... (Yukihiro Matsumoto) 2001/06/26

Hi,

[#16888] finalizers, destructors and whatnot — "David Leal" <david@...>

Hi all,

16 messages 2001/06/26

[#17037] keeping an Exception object alive — David Alan Black <dblack@...>

Hello --

19 messages 2001/06/28
[#17055] Re: keeping an Exception object alive — matz@... (Yukihiro Matsumoto) 2001/06/29

Hi,

[#17066] RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/06/29

Hello --

[#17076] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — matz@... (Yukihiro Matsumoto) 2001/06/29

Hi,

[#17079] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/06/29

Hello --

[#17138] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — matz@... (Yukihiro Matsumoto) 2001/07/02

Hi,

[#17141] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — David Alan Black <dblack@...> 2001/07/02

Hello --

[#17142] Re: RCR: Exception methods (was: Re: Re: keeping an Exception object alive) — ts <decoux@...> 2001/07/02

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

[ruby-talk:16156] Re: Strange idea... exporting from a scope

From: Stephen White <spwhite@...>
Date: 2001-06-01 19:08:54 UTC
List: ruby-talk #16156
On Sat, 2 Jun 2001, Yukihiro Matsumoto wrote:

> Yes.  And that's why it has not been merged yet.
> I'm still seeking the better way, if any.

My previous proposal was turned down on the basis that it broke existing
code. Given that upgrading code is possible with a version keyword, it
could be worth re-examining the proposal...

do/end blocks keep their flat scope, but the parameter list is extended
to make the variables shadowed/private.

  i = 1
  1.upto(10) {|i| i = i * 3 }
  puts i

will result in "1". If someone really wanted to define some local
variables, they could kludge this by popping a few more variable names
in the parameter list. Not nice, but it's easily understood and is not
an essential feature.

Another example:

  i = 123
  j = 10
  (1..10).each do |i|   # i becomes shadowed within the block
    j = i * 5
    k = i * 10
  end
  p [i, j, k]                  -> [123, 50, 100]

Next step...

Change the other block, {}, to have its own scope with all variables
being shadowed/private.

Eg:

  i = 123
  j = 10
  (1..10).each {|i|
    # accessing j at this point would be an error
    j = i * 5
    k = i * 10
  }
  p [i, j, k]                  -> [123, 10, accessing k is an error]

Eg, the code in the {}'s is just like it was a separate method. This
would also be a useful construct for testing the effect of refactoring
a block of code.

This would increase the semantic distance between the two block types
and make it clearer why there are two kinds of blocks.

It could also possibly eliminate the Proc/Method difference by making
{}s into syntactic sugar for an anonymous method definition or closure.

The <> construct can be used for the existing block definitions.

Regardless of whether this proposal makes it or not, I think updating
existing code is an interesting approach to the problem of how to upgrade
a language without breaking older code.

If old code can just be deprecated into clumsier syntax, then the new
changes to the language can always have access to the best syntax.

-- 
  spwhite@chariot.net.au

In This Thread