On Oct 11, 2010, at 21:26 , Josh C. wrote:
On Mon, Oct 11, 2010 at 9:58 PM, ara.t.howard [email protected]wrote:
-42.abs vs -42.abs()
In this case, the negative sign is also a method. Fully parenned, it looks
like 42.-@().abs() yikes!
ruby has negative numbers.
% echo “-42.abs” | parse_tree_show
s(:call, s(:lit, -42), :abs, s(:arglist))
On Monday, October 11, 2010 09:58:40 pm ara.t.howard wrote:
the only real argument for requiring parens is so that
o.foo # returns the method foo
as in javascript. other arguments are mostly religious.
I actually really like this about JavaScript, but as it turns out,
JavaScript
has getters and setters. I’m guessing they’ve been added to the language
itself because they pretty much always existed as part of the browser’s
API –
think “location.href = foo” – so it makes sense to expose them to
developers.
So here, the only real question is whether it’s more common to want to
deal
with methods directly this way, or to want to refactor instance
variables into
methods. I like that Ruby’s approach has everything entirely
encapsulated by
default – attr_accessor means I always have the option to replace an
instance
variable with a pair of methods. True, I have setters and getters in
JavaScript, but they’re the default in Ruby.
On Mon, 11 Oct 2010 01:21:22 -0500, Phillip G.
[email protected] wrote in
[email protected]:
[snip]
Same thing with block syntax. Whether to chose do…end or {…} is a
matter of taste, and what feels “right” in the circumstances.
Not entirely. There’s a difference in precedence that might be
relevant in some circumstances.
http://www.techotopia.com/index.php/Ruby_Operator_Precedence#Operator_Precedence_Table.
On Mon, Oct 11, 2010 at 09:25:15AM +0900, egervari wrote:
I just started playing around with ruby and rails, and one thing I’ve
noticed is that the style of the code is a little odd. People don’t
use parenthesis most or even all of the time.
[snip]
Thoughts?
My first thought was this:
“Parenthesis” is singular. “Parentheses” is plural. The second
sentence
of your message should have read as follows.
People don't use parentheses most or even all of the time.On Tue, Oct 12, 2010 at 6:20 PM, David M. [email protected]
wrote:
think “location.href = foo” – so it makes sense to expose them to developers.
So here, the only real question is whether it’s more common to want to deal
with methods directly this way, or to want to refactor instance variables into
methods. I like that Ruby’s approach has everything entirely encapsulated by
default – attr_accessor means I always have the option to replace an instance
variable with a pair of methods. True, I have setters and getters in
JavaScript, but they’re the default in Ruby.
I’m not sure I follow. It sounds like you’re saying that the
expression “o.foo” can mean either “invoke method foo on object o” or
“instance variable foo of object o”, depending on how o is defined.
But AIUI “o.foo” can only ever mean the former. (That method might be
an accessor for an instance variable, but you still can’t refer to an
instance variable directly using dot notation.)
On Oct 11, 7:58pm, “ara.t.howard” [email protected] wrote:
the only real argument for requiring parens is so that
o.foo # returns the method foo
as in javascript. other arguments are mostly religious.
Python is like Javascript in that regard.
$ python
def f(n=100): return n * 2
…
f
<function f at 0xb75ae6bc>
f()
200
x = f
x(30)
60
x = f()
x
200
$ irb
irb(main):001:0> def f(n=100) n * 2 end
=> nil
irb(main):002:0> f
=> 200
irb(main):003:0> f()
=> 200
irb(main):004:0> x = method(:f)
=> #<Method: Object#f>
irb(main):005:0> x.call(30)
=> 60
I work in both Python and Ruby, and I don’t have a strong preference
for either style; it just requires a different mindset.
On Mon, Oct 11, 2010 at 03:21:22PM +0900, Phillip G. wrote:
On Mon, Oct 11, 2010 at 6:04 AM, egervari [email protected] wrote:
Of course, once one gets used to it, I guess it’ll become readable.
Absolutely. A seasoned Perl vet will consider Perl code very readable,
too, after all.
Only well-written, readable Perl is particularly readable, even to a
“seasoned Perl vet” – just as only well-written, readable Ruby is
particularly readable, even to a “seasoned Ruby vet”.
Taking an example like what was brought up earlier, there are a bunch of
different ways to represent a complex expression:
10.div(10.div(5))
10.div( 10.div(5) )
10.div 10.div 5
10.div(10.div 5)
10.div( 10.div 5 )
10.div 10.div(5)
There are other options as well, but I have to stop some time. Anyway,
in my opinion, the worst of those for readability are 1 and 3. 2 and
6
are probably the next least-readable. It takes a little judgment to
write readable code, regardless of the language, and in cases where
parentheses are optional, I find that obsessive adherence to “always use
parentheses” or “never use parentheses” rules are not conducive to
producing the most readable code.
On Thu, Oct 14, 2010 at 09:51:19AM +0900, Eric C. wrote:
I’m not sure I follow. It sounds like you’re saying that the
expression “o.foo” can mean either “invoke method foo on object o” or
“instance variable foo of object o”, depending on how o is defined.
But AIUI “o.foo” can only ever mean the former. (That method might be
an accessor for an instance variable, but you still can’t refer to an
instance variable directly using dot notation.)
This is true but, to be fair, it can look an awful lot like direct
access
to the variable:
> class Foo
> def initialize(foo=nil)
> @foo = foo
> end
> attr_accessor :foo
> end
=> nil
> o = Foo.new
=> #<Foo:0x2854ec78 @foo=nil>
> o.foo = 'foo'
=> "foo"
> puts o.foo
foo
=> nilOn Thu, Oct 14, 2010 at 5:37 PM, Chad P. [email protected] wrote:
It takes a little judgment to
write readable code, regardless of the language, and in cases where
parentheses are optional, I find that obsessive adherence to “always use
parentheses” or “never use parentheses” rules are not conducive to
producing the most readable code.
In my opinion, parentheses should be used the way they are used in
maths: To make an ambiguous statement obvious.
For example: 2-x^2 can be interpreted in two ways: either (2-x) gets
squared, or only the x gets squared, and the product of this
subtracted from 2. Parentheses make the intention obvious: (2-x)^2.
It’s a simple guide, but it has a lot of repercussions, especially
once you take into account precedence of operators (which can allow
you to remove or “force” you to add parens).
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
On Wednesday, October 13, 2010 07:51:19 pm Eric C. wrote:
the language itself because they pretty much always existed as part of
I’m not sure I follow. It sounds like you’re saying that the
expression “o.foo” can mean either “invoke method foo on object o” or
“instance variable foo of object o”, depending on how o is defined.
My point was that JavaScript is like this, while Ruby is not. In
JavaScript,
ordinarily, ‘o.foo’ can only ever mean an instance variable (it has to
be
o.foo() to be a method, and if foo is a method, o.foo just gives you the
function object for that method). However, we can also specify a
function
which will be called whenever someone tries to access ‘o.foo’.
In other words, JavaScript makes it obnoxiously more tedious to either
use
normal setters and getters (for example, o.foo, o.setFoo(), and
o.getFoo()),
and even more tedious to define first-class setters and getters (so
trying to
set or get o.foo actually calls your custom code instead). However, it
makes
it very easy to remix objects, with far more flexibility and with a far
more
primitive concept than mixins.
Ruby, by contrast, makes setters and getters easy (and required), which
means
encapsulation is much easier – but it makes certain kinds of code
re-use
harder, and forces you to use classes and modules, whereas JavaScript
starts
out with something simpler (prototypal inheritance), and allows you to
pretty
much build any inheritance model you like on top of that.
Anyway, this is all about syntax. JavaScript makes it easier to do
things one
way, Ruby makes it easier another way, but everything I mentioned should
be
possible in both. It’s just a question of how ugly it will be.
On Fri, Oct 15, 2010 at 07:28:16AM +0900, Eric C. wrote:
This is true but, to be fair, it can look an awful lot like direct access
=> #<Foo:0x2854ec78 @foo=nil>o.foo = ‘foo’
=> “foo”
puts o.foo
foo
=> nilRight, but I don’t see what it has to do with the optionality of
parentheses. The point made earlier (one I’d seen before) was that the
optionality of parentheses made refactoring easy.
I think David M.'s response of 15 October answers this question of
yours, so I’ll let that message speak for the matter of the optionality
of parentheses help with refactoring. I’ll just offer this
oversimplified summary:
When you do not need to differentiate between a call to what amounts to
an instance variable and a call to a method that returns the value of an
instance variable by using parentheses, swapping out the back end of
that
call does not require changing the syntax of all relevant calls.
In short, it doesn’t change the behind-the-scenes work done to refactor
your code, but it changes the “superficial” work that has to be done
because the call changed from (in effect) a straightforward variable
evaluation to a method call that returns the value of that variable, or
vice versa.
On Thu, Oct 14, 2010 at 10:22 AM, Chad P. [email protected] wrote:
to the variable:
o.foo = ‘foo’
=> “foo”
puts o.foo
foo
=> nil
Right, but I don’t see what it has to do with the optionality of
parentheses. The point made earlier (one I’d seen before) was that the
optionality of parentheses made refactoring easy.
David said:
So here, the only real question is whether it’s more common to want to deal
with methods directly this way, or to want to refactor instance variables into
methods. I like that Ruby’s approach has everything entirely encapsulated by
default – attr_accessor means I always have the option to replace an instance
variable with a pair of methods.
Sure, within a class you can replace the instance variable @foo with
the accessor methods foo and foo= (with or without parentheses), or
vice versa; but you still need to add or remove the @ sign when you
change between instance variable and method.
The only context I can think of where a given token can refer to
either a method call or a variable is within a method or other block
that allows local variables. E.g.:
def foo
…
puts x
…
end
Here, if you don’t look at the whole method, you can’t tell if “x”
refers to a local variable x, or a method call equivalent to self.x.
However, if you look at the whole method, you can see whether x is
ever assigned to; if it is assigned to without using “self.”, you know
it’s a local variable.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs