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

Rick Johnson rantingrickjohnson at gmail.com
Tue Mar 27 22:22:45 EDT 2018


On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
[...]
> > Since when did utilizing a method to request a specific
> > value become some sort of magic?
>
> Since it requires a special method that has super powers no
> method you can write yourself can do.

That's hilarious. I guess you never called __init__? LOL!

> Can you write a pure-Ruby method that does the same thing
> as Object.method, using only standard, public parts of the
> Ruby API? No special debugger hooks or "subject to change
> without warning" internal APIs or other private
> implementation details.

I'm not your personal tutor, Steven. And i'm not about to
waste one second of my time writing a solution to a non-
problem. Ruby already provides a well-known mechanism to
retrieve the method object. If you seek assistance, why
don't you go over the Ruby-list and ask them for help. I'm
sure they'd be very eager to help after hearing all the nice
things you've said about Ruby.

> > Even though i prefer Python's way better, the implicit
> > return of Python function references is far more "magical"
> > than making an explicit call to a method will ever be.
>
> Let's say you have an object, lassie = Dog(). How do you
> get access to her tail? Do you use dot syntax:
>
>     lassie.tail

I dunno, because you failed to provide a class definition
for `Dog`, so i have nothing to go on save this horrid
explanation of yours. It'd be like me asking you to list the
contents of my refrigerator. Listen, post a code sample and
then i'll comment on it. Until then, don't expect me to read
your mind.

> [snip: more questions about some mysterious Dog class
> (probably stored at Area 51!)]
>
> Ruby attributes are always private.

Indeed. Unlike Python, Ruby is a pure OO language, and thus,
demands that public attributes must be explicitly made
public. Think of Ruby as existing somewhere between Python
and Java. Ruby tries to be as pure about OOP as it can
without becoming as onerous as Java. So yeah, you can safely
assume that Python and Ruby are not the same language
(surprising, i know!)

> You must write accessor getter and setter methods if you
> want to access them from outside the instance or class.

Yes. Unlike Python, Ruby doesn't believe in the philosophy
of "consenting adults" (where privatization of attributes
and methods is done using something as ridiculously brittle
as leading underscores [insert laugh track here]). And Ruby
sure as heck does not promote the utterly annoying Python
misfeature otherwise known as "name mangling".

Which reminds me!!!

So you think Ruby is the _only_ language that has
misfeatures? Well, feast your eyes on this Python
perversion!

    >>> class Fu(object):
    	def bar1(self):
    		pass
    	def _bar2(self):
    		pass
    	def __bar3(self):
    		pass
    >>> fu = Fu()
    >>> [name for name in dir(fu) if 'bar' in name]
    ['_Fu__bar3', '_bar2', 'bar1']

What happened to the method named "__bar3"?

Where did it go?

"Hey Python, I want my symbol back!"

Tip: Better go check Area 51, cause i assure you, Steven,
you won't find that symbol anywhere in Python. It's gone
dude! Off in another parallel universe. Probably hangin'
with the Squaches and eatin' beef jerky, for all we know.

And to think! During this entire thread you have gone out of
your way to call Ruby inconsistent and accuse her of
returning surprising results... well then... tell us Mr.
D'Aprano, how does the crow taste? Hmm?

> But once you have those accessors, you can use lassie.tail
> to access the member (attribute) tail, and lassie.bark to
> *call* the method. There is no member "bark" because
> methods aren't values.

Care to provide some code that will prove your point? Or are
we condemned to suffer more of these horrid explanations of
yours?

PS: If you need help writing the Dog class, send me a PM.
And if you're nice, maybe i'll help.



More information about the Python-list mailing list