Arggh, the scary part is you wont even know if you've been shot
until you're dead --too late. I myself do not like block args (or
any args for that matter) clobbering local, global, and instance
vars. Surely, it is not the intent of the programmer to clobber
them, nor is it an intuitive intent to peek on arg values from the
outside (is that being obj-oriented?). I clobber what i clobber.
When coding an arg var, surely i do not need to bother and question
myself "will this var clobber other vars?". Ruby should help me on
that, not put fear on it. I wonder what is the original intent of
matz when he designed that feature. It is scary. I've been hit by
it. And now i have to be careful about naming my vars.
Is that bad?
Is shadowing
arg vars really used much in practice? It is not a fun part of ruby
if you ask me. or maybe, it is just too much fun for me. forgive the
non-ruby-hacker, pls
But you always have to avoid clobbering variables:
x = 1
...
x = gets
...
if x > 0 # blows up
I think the only hurdle is just realizing that:
{|x| ... }
is an assignment to x. After that, it's no more dangerous or
error-prone than any other occasion when you have to choose a name for
a temporary (or not) variable and assign to it.
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
On 9/9/07, Logan Capaldo <logancapaldo@gmail.com> wrote:
On 9/9/07, Bernardo Monteiro Rufino <bermonruf@gmail.com> wrote:
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
As far as remember, Guy Decoux and I are the only two people who think
that this makes perfect sense, once you learn it, and should not be
changed
This one is my favorite.
P.S. Don't use this in 'real' code or I will be forced to hunt you
like a wild animal through the streets of your city. =(
>cat eye_of_terror.rb
h = {}
f = lambda {|h[:x]| }
f[7]
p h
>ruby eye_of_terror.rb
{:x=>7}
Hey, nothing wrong with that -- it's just like
h[:x] = 7
but in slightly different form. But like I said, I'm one of the few
who think that there's nothing wrong with assignment semantics for
block parameters
I agree, except for the fact that assignments are relatively static,
while 'yield' calls are variadic. Please tell me you don't use this
feature, David.
Hash#each do {|h[:x]| ... } is.. pretty strange.
I've never used h[:x] as a block parameter. That is a bit exotic, and
a bit useless But I think I've used an instance variable. Also
it's handy if, for example, you want to capture the last value passed
during an iteration.
is an assignment to x. After that, it's no more dangerous or
error-prone than any other occasion when you have to choose a name for
a temporary (or not) variable and assign to it.
It's not though. It's _almost_ like an assignment to x, except when
it's like passing a parameter. If it really was always just assigning
to x, my example would overflow in both cases, which while not my
personal ideal, would make me happier than the current situation.
···
On 9/11/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
I would be OK-er with this if method arguments obeyed the same rules.
e.g.
def foo=(@foo);end
foo = 5
would then automatically set the instance variable for you.
I think I mostly don't like it because it is unique to block
arguments, and even then is pretty significantly different in
'regular' blocks vs. lambdas.
···
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
> On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>>
>> On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
>>
>>> On 9/9/07, Logan Capaldo <logancapaldo@gmail.com> wrote:
>>>> On 9/9/07, Bernardo Monteiro Rufino <bermonruf@gmail.com> wrote:
>>>>> On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>>>>
>>>>>> As far as remember, Guy Decoux and I are the only two people who think
>>>>>> that this makes perfect sense, once you learn it, and should not be
>>>>>> changed
>>>>>>
>>>
>>> This one is my favorite.
>>> P.S. Don't use this in 'real' code or I will be forced to hunt you
>>> like a wild animal through the streets of your city. =(
>>>
>>> >cat eye_of_terror.rb
>>> h = {}
>>> f = lambda {|h[:x]| }
>>> f[7]
>>> p h
>>>
>>> >ruby eye_of_terror.rb
>>> {:x=>7}
>>
>> Hey, nothing wrong with that -- it's just like
>>
>> h[:x] = 7
>>
>> but in slightly different form. But like I said, I'm one of the few
>> who think that there's nothing wrong with assignment semantics for
>> block parameters
>>
>>
>
> I agree, except for the fact that assignments are relatively static,
> while 'yield' calls are variadic. Please tell me you don't use this
> feature, David.
>
> Hash#each do {|h[:x]| ... } is.. pretty strange.
I've never used h[:x] as a block parameter. That is a bit exotic, and
a bit useless But I think I've used an instance variable. Also
it's handy if, for example, you want to capture the last value passed
during an iteration.
Actually I believe David is right. It *is* just an assignment to x
but you have to keep in mind the scoping rules of blocks. Basically
the notation |x| is just a shortcut for an assignment with a parameter
when the block is called. But the general scoping rule for local
variables in blocks is that they are block local when not defined
outside of the block. This is the same regardless whether a var name
occurs between bars or on the left side of an assignment.
On 9/11/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>
> I think the only hurdle is just realizing that:
>
> {|x| ... }
>
> is an assignment to x. After that, it's no more dangerous or
> error-prone than any other occasion when you have to choose a name for
> a temporary (or not) variable and assign to it.
>
It's not though. It's _almost_ like an assignment to x, except when
it's like passing a parameter. If it really was always just assigning
to x, my example would overflow in both cases, which while not my
personal ideal, would make me happier than the current situation.
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
On 9/9/07, Logan Capaldo <logancapaldo@gmail.com> wrote:
On 9/9/07, Bernardo Monteiro Rufino <bermonruf@gmail.com> wrote:
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
As far as remember, Guy Decoux and I are the only two people who think
that this makes perfect sense, once you learn it, and should not be
changed
This one is my favorite.
P.S. Don't use this in 'real' code or I will be forced to hunt you
like a wild animal through the streets of your city. =(
>cat eye_of_terror.rb
h = {}
f = lambda {|h[:x]| }
f[7]
p h
>ruby eye_of_terror.rb
{:x=>7}
Hey, nothing wrong with that -- it's just like
h[:x] = 7
but in slightly different form. But like I said, I'm one of the few
who think that there's nothing wrong with assignment semantics for
block parameters
I agree, except for the fact that assignments are relatively static,
while 'yield' calls are variadic. Please tell me you don't use this
feature, David.
Hash#each do {|h[:x]| ... } is.. pretty strange.
I've never used h[:x] as a block parameter. That is a bit exotic, and
a bit useless But I think I've used an instance variable. Also
it's handy if, for example, you want to capture the last value passed
during an iteration.
I would be OK-er with this if method arguments obeyed the same rules.
e.g.
def foo=(@foo);end
foo = 5
would then automatically set the instance variable for you.
I think I mostly don't like it because it is unique to block
arguments, and even then is pretty significantly different in
'regular' blocks vs. lambdas.
It's definitely different from method-param semantics. It's never
bothered me, though -- it's just a different decision about how block
params will work.
I'm not sure what you mean when you say different between regular
blocks and lambdas -- ?
>
> >
> > I think the only hurdle is just realizing that:
> >
> > {|x| ... }
> >
> > is an assignment to x. After that, it's no more dangerous or
> > error-prone than any other occasion when you have to choose a name for
> > a temporary (or not) variable and assign to it.
> >
> It's not though. It's _almost_ like an assignment to x, except when
> it's like passing a parameter. If it really was always just assigning
> to x, my example would overflow in both cases, which while not my
> personal ideal, would make me happier than the current situation.
Actually I believe David is right. It *is* just an assignment to x
but you have to keep in mind the scoping rules of blocks. Basically
the notation |x| is just a shortcut for an assignment with a parameter
when the block is called. But the general scoping rule for local
variables in blocks is that they are block local when not defined
outside of the block. This is the same regardless whether a var name
occurs between bars or on the left side of an assignment.
I'm pretty sure everything you said is factual. I still think it's wrong.
···
On 9/12/07, Robert Klemme <shortcutter@googlemail.com> wrote:
I was referring (poorly) to the fact that lambdas enforce arity but
regular blocks do not.
···
On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
> On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>>
>> On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
>>
>>> On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>>> Hi --
>>>>
>>>> On Mon, 10 Sep 2007, Wilson Bilkovich wrote:
>>>>
>>>>> On 9/9/07, Logan Capaldo <logancapaldo@gmail.com> wrote:
>>>>>> On 9/9/07, Bernardo Monteiro Rufino <bermonruf@gmail.com> wrote:
>>>>>>> On 9/9/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>>>>>>
>>>>>>>> As far as remember, Guy Decoux and I are the only two people who think
>>>>>>>> that this makes perfect sense, once you learn it, and should not be
>>>>>>>> changed
>>>>>>>>
>>>>>
>>>>> This one is my favorite.
>>>>> P.S. Don't use this in 'real' code or I will be forced to hunt you
>>>>> like a wild animal through the streets of your city. =(
>>>>>
>>>>> >cat eye_of_terror.rb
>>>>> h = {}
>>>>> f = lambda {|h[:x]| }
>>>>> f[7]
>>>>> p h
>>>>>
>>>>> >ruby eye_of_terror.rb
>>>>> {:x=>7}
>>>>
>>>> Hey, nothing wrong with that -- it's just like
>>>>
>>>> h[:x] = 7
>>>>
>>>> but in slightly different form. But like I said, I'm one of the few
>>>> who think that there's nothing wrong with assignment semantics for
>>>> block parameters
>>>>
>>>>
>>>
>>> I agree, except for the fact that assignments are relatively static,
>>> while 'yield' calls are variadic. Please tell me you don't use this
>>> feature, David.
>>>
>>> Hash#each do {|h[:x]| ... } is.. pretty strange.
>>
>> I've never used h[:x] as a block parameter. That is a bit exotic, and
>> a bit useless But I think I've used an instance variable. Also
>> it's handy if, for example, you want to capture the last value passed
>> during an iteration.
>>
>>
>
> I would be OK-er with this if method arguments obeyed the same rules.
> e.g.
> def foo=(@foo);end
>
> foo = 5
> would then automatically set the instance variable for you.
> I think I mostly don't like it because it is unique to block
> arguments, and even then is pretty significantly different in
> 'regular' blocks vs. lambdas.
It's definitely different from method-param semantics. It's never
bothered me, though -- it's just a different decision about how block
params will work.
I'm not sure what you mean when you say different between regular
blocks and lambdas -- ?
