2011/10/4 Jesús Gabriel y Galán [email protected]:
2011/10/4 Bartosz Dziewoński [email protected]:
- Block arguments and block-local variables
Block arguments and block local variables are local to the block
scope, not the method.
If I understand the discussion correctly, the fact to what scope
exactly they are local doesn’t matter; once it’s defined, bareword
reference will resolve to the variable, not the method anymore. Of
course, after the block it will resolve to the method again.
irb(main):002:0> def x; ‘foo’; end
=> nil
irb(main):003:0> x
=> “foo”
irb(main):004:0> 3.times{|x| p x}
0
1
2
=> 3
- Stabby Lambda variables
What do you mean by this?
Regular lambda: a = lambda{|x,y| x+y} - it cant have, for example,
default value for arguments.
“Stabby” lambda, or “arrow” lambda: a = ->(x=5, y=6){x+y} = as you can
see, it’s arguments work just like function’s ones.
- Rescue exception naming (rescue StandardError => err)
Kind of assignment 
Well, certainly not a regular one 
– Matma R.
2011/10/4 Bartosz D. [email protected]:
course, after the block it will resolve to the method again.
Well, I was referring to creating a local variable in the scope of the
method, and trying to somewhat fight for my statement :-).
But you are right, block arguments create local variables in its scope.
- Stabby Lambda variables
What do you mean by this?
Regular lambda: a = lambda{|x,y| x+y} - it cant have, for example,
default value for arguments.
“Stabby” lambda, or “arrow” lambda: a = ->(x=5, y=6){x+y} = as you can
see, it’s arguments work just like function’s ones.
Ah, ok.
- Rescue exception naming (rescue StandardError => err)
Kind of assignment
Well, certainly not a regular one
Sure, in all your examples, someone, somewhere assigns a value to that
variable, maybe it’s under the hood, but there’s an assignment. That’s
my argument (very shaky, I admit) to try to hold my statement. You are
right there are other ways of having the parser understand that
something is a local variable other than a pure assignment expression,
although I still contend that method arguments, block arguments,
lambda default values for arguments and exceptions are still
assignments in a sense :).
Jesus.
On Oct 4, 2011, at 5:15 PM, Adam P. wrote:
As far as I know, ->{} is absolutely no different from lambda {}.
I’m not sure what bugs me so much about ‘stabby lambda’ but I just don’t
like it. The only advantage I can see is that since it is syntax, there
might be some parse-time optimization that can be employed during
construction of the lambda. Since ‘lambda’ is a method invocation and
not a keyword these optimizations might not be possible with ‘lambda’.
Charles Nutter might have some words of wisdom on that since it is
similar to the obstacles associated with eval being a method and not a
keyword.
Gary W.
On Tue, Oct 4, 2011 at 9:06 PM, Gary W. [email protected] wrote:
Nutter might have some words of wisdom on that since it is similar to the
obstacles associated with eval being a method and not a keyword.
Gary W.
I’ve started using it in RSpec.
→ { whatever }.should_not raise_error
lambda { whatever }.should_not raise_error
I prefer the former. Almost all the rest of the time, I prefer the
latter.
2011/10/4 Bartosz Dziewoński [email protected]
- Stabby Lambda variables
What do you mean by this?
Regular lambda: a = lambda{|x,y| x+y} - it cant have, for example,
default value for arguments.
?
l = lambda { |x, y=2| [x,y] }
=> #<Proc:0x8d383a0@(irb):1 (lambda)>
l.call(1)
=> [1, 2]
RUBY_VERSION
=> “1.9.2”
As far as I know, ->{} is absolutely no different from lambda {}.
Darryl Pierce wrote in post #1025016:
On 10/04/2011 11:42 AM, Chris H. wrote:
but doing it this way makes the x public readable, so should only be
used if that is needed
I’d stick with using @x
AH! That’s what I missing, and what he meant by “the method”. Okay. The
OP though didn’t have the attr_accessor on the fields, though, that I
remember.
This was implied by the use of ‘other.x’. If you can write ‘other.x’
then that object must have a method called ‘x’. Since we’re talking
about adding two objects of the same class, this means self also has a
method ‘x’, and you can call this just using ‘x’.
Now, if you don’t want to have accessors on your Point class, then it
gets a little bit messy to tinker with the internals of the other
object: e.g.
@x + other.instance_variable_get(:@x)
or
@x + other.instance_eval { @x }
I think you could also use a ‘protected’ accessor method, but I’ve never
found the need to use those.
On Wed, Oct 5, 2011 at 4:00 AM, Brian C. [email protected]
wrote:
This was implied by the use of ‘other.x’. If you can write ‘other.x’
or
@x + other.instance_eval { @x }
I think you could also use a ‘protected’ accessor method, but I’ve never
found the need to use those.
–
Posted via http://www.ruby-forum.com/.
For that, you could use protected:
class UselessPoint
def initialize(x, y)
@x, @y = x, y
end
def +(point)
UselessPoint.new point.x+x, point.y+y
end
protected
attr_reader :x, :y
end
p1 = UselessPoint.new 1, 2
p2 = UselessPoint.new 3, 4
p1 + p2 # => #<UselessPoint:0x007fdc6208b970 @x=4, @y=6>
p1.x # =>
~> -:19:in <main>': protected method x’ called for
#<UselessPoint:0x007fdc6208ba10 @x=1, @y=2> (NoMethodError)
2011/10/4 Adam P. [email protected]:
?
As far as I know, ->{} is absolutely no different from lambda {}.
Huh, that’s true, I didn’t realize - it didn’t work on 1.8.x. I though
it wouldn’t work for example due to ambiguity with the |
method/operator:
a = lambda{|x, y=x|2| x+y}
Interestingly, it works. (But probably not the way you would expect.)
– Matma R.