Ruby parens-free function calls [was Re: Accessing parent objects]

Rick Johnson rantingrickjohnson at gmail.com
Tue Mar 27 08:29:31 EDT 2018


On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> Printing a string and calling a function is obfuscated code? Deary me.

When the programmer can't be bothered to invent names more
descriptive than `a` and `b`, why yes, yes it is.

> And besides, while I'm more than happy to take (undeserved)
> credit for all the things Ruby gets right, I draw the line
> at being blamed for Ruby misfeatures like parens-less
> function calls, and the inconsistent behaviour they lead
> to.

What version are you testing this "misfeature" on?
Personally, I'm using 1.9, so i have no idea if the
"misfeature" has been repaired or not. The latest stab;e
release is 2.5.0. There have been a ton of changes since
1.9!

> > > Because of this "fix", the printed strings no longer
> > > match the code being executed, but the strange,
> > > inconsistent behaviour still occurs.
> > 
> > The supposed "inconsistent behavior" here has absolutely
> > nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> > the one who created a non-sensical function
> 
> I love watching you trying to squirm your way out of
> admitting that you screwed up. Returning the input plus two
> is nonsensical is it?

When the function is named `a`, why yes, yes it is!

> As I said, don't blame me for Ruby's poor design.  By the
> way, there are precisely the same number of clues that:  a
> is a function as there are for:  super  in Ruby. But you
> know that, because you were vehemently defending the use of
> super with no parens and why it isn't inconsistent for it
> to do something completely different from super() with
> parens.

Okay, Mr. "Language Designer"... how do _you_ propose to
implement Ruby's super in a way that provides these same
three distinct forms:

    (1) implicit passing of args: `super`
    (2) explicit passing if args: `super(arg1, arg2, ..., argN)`
    (3) no arg passing: `super()`
        
Let's hear it! And don't forget to make your design
consistent with func/meth calls, even though super is not a
func at all -- but i digress!

> So now you're claiming I hacked the Ruby interpreter to
> support non- standard code? I can smell the desperation in
> you from the other side of the planet.  Rick, nothing I did
> was illegal Ruby code. Everything I did was 100% following
> the rules of the Ruby language.

The rules you violated were _style_ and _sanity_ rules.
Every wise programmer knows that readability dictates one
space on each side of an operator:

    YES: a + b
    NO: a+b
    NO: a+ b
    NO: a +b
    HELL NO: a    +       b
    
Ruby is punishing you for your petulant behavior. And if i
were you, i'd be kissing Matz's backside for only giving you
a "surprising result". Because if *I* were the creator of
Ruby, i'd have Ruby format your hard-drive for doing _less_.

But i look forward to your proposed solutions to Ruby's so-
called "broken expressions and inconsistent super". Oh guru,
please enlighten us with your language design wisdom.



More information about the Python-list mailing list