On Mon, 11 Oct 2010 01:21:22 -0500, Phillip Gawlowski
<cmdjackryan@googlemail.com> wrote in
<AANLkTim6R2Bv-xf4LcEHMS4P9cFkx8MxyoJbjU5i-bHo@mail.gmail.com>:
[snip]
Same thing with block syntax. Whether to chose do...end or {...} is a
matter of taste, and what feels "right" in the circumstances.
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 Tue, Oct 12, 2010 at 6:20 PM, David Masover <ninja@slaphack.com> wrote:
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.
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:
1. 10.div(10.div(5))
2. 10.div( 10.div(5) )
3. 10.div 10.div 5
4. 10.div(10.div 5)
5. 10.div( 10.div 5 )
6. 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 Mon, Oct 11, 2010 at 03:21:22PM +0900, Phillip Gawlowski wrote:
On Mon, Oct 11, 2010 at 6:04 AM, egervari <ken.egervari@gmail.com> 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.
You really come across like the kind of person who goes to Japan and says
"look how much fish these people eat, look how strange the roofs of their
houses are, look how many characters are in their alphabet. This place
sucks, it isn't at all like where I come from."
···
On Mon, Oct 11, 2010 at 4:04 AM, egervari <ken.egervari@gmail.com> wrote:
In Scala, you have the option, just like Ruby, but there is a clear
sense of when and when not to use it. It's not really arbitrary when
working with Scala code. I usually find myself just knowing when it's
best to drop the . and () and when to include it. I have no such
guideline really with Ruby, as a lot of code seems to make this choice
arbitrary. For the time being as I learn, I'm just using parenthesis
to avoid confusion.
Oh, your ruby example is valid syntax? I will try it. There's no way I
would even conceive of writing code like that. I hope others don't
either.
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.
For what it's worth, this is also the case for most operators in Ruby, it's
just that pretty much all Ruby operators have special syntax. This makes
sense, I think -- for example,
a.foo = b
is equivalent to
a.foo=(b)
which seems a lot more manageable to me than
a.foo.=(b)
What would a.foo be returning, then? You could do it, it would just be clumsy,
and wouldn't work nearly as well with immutable types -- and all the basic
Ruby numeric types are immutable.
···
On Monday, October 11, 2010 03:55:18 am egervari wrote:
In scala, there is no difference between operators and methods. They
are all methods.
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
=> nil
···
On Thu, Oct 14, 2010 at 09:51:19AM +0900, Eric Christopherson wrote:
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).
···
On Thu, Oct 14, 2010 at 5:37 PM, Chad Perrin <code@apotheon.net> 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.
--
Phillip Gawlowski
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.
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 Wednesday, October 13, 2010 07:51:19 pm Eric Christopherson wrote:
On Tue, Oct 12, 2010 at 6:20 PM, David Masover <ninja@slaphack.com> wrote:
> 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.
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.
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
=> 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.
···
On Thu, Oct 14, 2010 at 10:22 AM, Chad Perrin <code@apotheon.net> wrote:
On Thu, Oct 14, 2010 at 09:51:19AM +0900, Eric Christopherson wrote:
I think David Masover'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 Fri, Oct 15, 2010 at 07:28:16AM +0900, Eric Christopherson wrote:
On Thu, Oct 14, 2010 at 10:22 AM, Chad Perrin <code@apotheon.net> wrote:
> On Thu, Oct 14, 2010 at 09:51:19AM +0900, Eric Christopherson 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
> => 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.
