Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "what is the difference between Ruby and Python method calls". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Property-vs- Method

In Python's worldview, an object is treated as a container for properties on which callers can get/set properties. The logic of get/set may be simple value assignment, or it may be complex logic implemented through descriptor. The so-called method simply returns a special callable object when looking for property.

Ruby follows the design principle of Smalltalk: message passing is the only way for objects to communicate with the outside world, and attribute assignments and values are method calls under the guise of syntax sugar. That's all.

Method analysis

The word parsing is translated from Resolution, and method parsing is sometimes referred to as method Lookup. The problem to be solved in the parsing process is to "find the code that actually needs to be executed when accepting the method call."

Because of Python's emphasis on the concept of "attribute" and its descriptor, method parsing should be called attribute parsing in Python.

Start with the instance itself

Ruby designed eigenclass so that each instance can have its own class, in which it defines its own method, and eigenclass has the highest priority in the process of method parsing. After all, from a messaging point of view, it is not too much for the object to decide how to respond to the message.

In daily application development, the most common time to use eigenclass is to define class methods. Another common technique is to cache dynamic generation methods in it. The Test double library makes full use of it to define the behavior of each instance.

In contrast to Python, support for Per-instance Polymorphism stays on the basis of instance properties. In other words, the instance itself is simply a property container. If you really want to play, just change the _ _ class__ property of the object. one

Parsing along inheritance structure

Finding the path according to the inheritance structure of the class is the most important way to find the path, and it is the key knowledge that needs to be understood when learning the object model of the two languages.

Although Ruby uses mixin, Python uses multiple inheritance. However, there is no great difference in the function of the two mechanisms.

Of course, there are special cases: Python allows developers to modify the method resolution path of an instance of class by customizing the .mro () method of an class metaclass. It is not clear how many applications there are in this interface that significantly changes the search order of the method.

In addition, the property lookup order of the Python object instance is obviously crossed with that of its class. Both staticmethod and classmethod, which semantically only belong to class, appear on the instance's property lookup path. Maybe this is to facilitate the use of staticmethod, which exists mostly as utility function, but it also means that you can't let class method and instance method/property have the same name. Seriously, it's strange to get class method from an example no matter how you explain it.

Fallback when parsing fails

Python has the opportunity of _ _ getattr__ for developers to return an attribute when parsing fails. Accordingly, Ruby has method_missing, but you need to return the result of the method call instead of simply looking for it. This is obviously a product of message passing mode: you need to respond to message instead of focusing on concepts such as properties / methods.

In addition, Python can also call _ _ getattribute__ / _ _ setattr__, before finding it, which is also an opportunity for catch-all. Oh, by the way, _ _ getattribute__ can intercept the lookup of so-called "special attributes" (such as _ _ dict__), while _ _ getattr__ cannot.

In this respect, purely from the perspective of language ability, Ruby seems to be weaker. However, providing only the catch-all that failed to find is sufficient to "respond to arbitrary method calls." And, does anyone remember those special attributes of Python? This kind of design with no difference in grammar but vaguely different logic behind it can either memorize it or wait for it to fall into the hole.

Method binding and calling

Finally, after talking about the method parsing, the next process becomes simple. The so-called binding is simply to let the unbound method determine the direction of the self when it is called. It is sometimes called context in my impression.

In Python's method definition syntax, binding self looks a lot like binding the first parameter to a function. I don't know if it's the same as the so-called currify. Even, if you pass in the wrong number of arguments during the call, the self placeholder will be included in the exception message thrown by Python, effectively disturbing your debugging. Ruby certainly doesn't have this problem.

And, because of the emphasis on "messaging", unlike Python, Ruby can omit the parentheses at the time of the call and return a bound method directly, but must be implemented with another method, Object#method.

On the other hand, Python complicates syntax-semantics here, while Ruby chooses to cram this underlying logic into a seemingly innocent method. So Ruby is able to "omit parentheses when a method is called." It is because Ruby does not rely on complex syntax to express semantics that it can make room for more grammatical sugars.

That's all for "what's the difference between Ruby and Python's method calls?" Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.