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.
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
5. 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.
On Wed, Oct 5, 2011 at 4:00 AM, Brian Candler <b.candler@pobox.com> wrote:
Darryl Pierce wrote in post #1025016:
> On 10/04/2011 11:42 AM, Chris Hulan 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.
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.
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.
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
5. 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.
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 :).
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 Wright
···
On Oct 4, 2011, at 5:15 PM, Adam Prescott wrote:
As far as I know, ->{} is absolutely no different from lambda {}.
I prefer the former. Almost all the rest of the time, I prefer the latter.
···
On Tue, Oct 4, 2011 at 9:06 PM, Gary Wright <gwtmp01@mac.com> wrote:
On Oct 4, 2011, at 5:15 PM, Adam Prescott 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.
