[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5617] Re: local variables (nested, in-block, parameters, etc.)

From: "Brian F. Feldman" <green@...>
Date: 2000-10-16 23:14:04 UTC
List: ruby-talk #5617
Dave Thomas <Dave@thomases.com> wrote:
> matz@zetabits.com (Yukihiro Matsumoto) writes:
> 
> > For example:
> > 
> >   lambda{<a,b,c|d,e,f> ...}
> >   # a,b,c as parameters.
> >   # d, e, f for local variables valid during the block.
> 
> Seems like the best of both worlds (except you'd probably need a
> character other than '|' as the separator, for the case where you want 
> non-local parameters but local variables.
> 
>    lambda { <a,b % c, d> ... }   local params and local vars
> 
>    lambda { |a,b % c, d| ... }   current params and local vars

I really, really dislike this discussion (please hear me out).  This syntax 
itself isn't too bad, probably useful enough to some people, but I honestly 
believe the problem is exactly as the first poster stated and nothing more.  

If I have the code:

	x = 0	# must initialize x anyway for it to be bound this way
	(1..3).each {|x| puts x}
	puts "Last was ", x

How is it nearly as clean as:

	x = 0	# must initialize x for it to be accessible by the block
	(1..3).each {|y| x = y; puts x}
	puts "Last was ", x

?  The former is just not useful at all.  It violates POLA because it 
introduces a scoping rule that makes things harder on the user by requiring 
them to remember every local variable already used if they don't want to 
accidentally mess something up.

The user already has to explicitly initialize a variable that he wants the 
block to modify.  You won't make it easier on people who know what they're 
doing because they already know the scoping rules; you won't make it easier 
for newbies because they would never expect  the current behavior.

The behavior as it is now is harmful because it is not consistent with 
methods (and a lambda is just that, an anonymous method...).  The form of
lambda {<a, b | e, f>} doesn't make things easier to understand (the user 
still has to look specifically for if whether e and f are already defined to 
determine if they will be local or not).

Oh well.  It doesn't seem like there is a compelling reason to not make 
variables automatically localized to the block.  What's useful would be a 
local variable but non-parameter syntax, a way to be sure that if you see 
only this little bit of code that you know it won't reach outside of its 
bounds.  But inheriting variables in the _arguments_ to a block is just 
inconsistent, and it should be no question of whether or not there should be 
a syntax to allow both...

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'



In This Thread