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

This article mainly explains "what is the difference between the object system of Ruby and Python". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what's the difference between Ruby and Python's object system?"

Attribute

The strict definition of the attribute does not know where to find it, so it is used here to refer to the way in which the object instance stores its own state. The natural purpose is to store the collaborators and data of the object. Or simply put it: everything in per-instance is called attribute 1.

Internal access

Generally speaking, the internal state of the object is not easily exposed to the outside, and the read and write operations are mainly done by the object's methods. This kind of access, which quietly modifies its own properties, is temporarily called internal access.

Ruby provides a separate namespace for each object to hold attributes. Syntactically @ foo is read and @ foo = 'bar' is write. And read-write semantics cannot be interfered with by metaprogramming. It does not conflict with constant lookup, method invocation, local variable access and other addressing methods.

This namespace also seems to exist in Python, and at first glance 2 can be accessed through the _ _ dict__ dictionary. However, due to too much typing, I am afraid that few people actively use it, and more often use external access directly. Look down.

External access

Ruby prohibits external direct access to object property 3 by default, which requires us to explicitly use attr series methods in the class definition to explicitly define access methods for external use.

Python is much easier on this side. Custom New Style Class has a _ _ dict__ attribute 4 by default, which is fully open for reading and writing, and can be accessed directly using foo.bar,foo.bar = 'baz' syntax, which is mostly used for internal access.

I don't want to talk about defining _ _ slots__ here, because looking at a long list of notes in the document that you need to watch out for, you can guess that few people want to use it. The result of a little Google basically confirmed this.

Metaprogramming: custom getter/setter

Both languages support syntactically writing regular attribute values / assignments while executing arbitrary code behind them. Common scenarios include deferred evaluation, Calculated Attribute, read-only attributes, and so on.

In Ruby, because the syntax sugar is so sweet, parentheses can be omitted when calling a method. The method that can be called without passing parameters is getter, which is written like foo.bar. The unary method that ends with = is setter, which is called through foo.bar = 'baz'. The attr series of methods mentioned earlier only define methods according to this interface, not special language keywords.

As for Python, it's okay to use the @ property decorator when you just need getter. But there is some trouble when you need to allow external read-only access to properties. Read and write control is implemented by property descriptor, in order to customize a read-only descriptor to write like this:

EDIT: obviously the following code is wrong, what I was thinking at the time. Fortunately, in the real world, underlining schemes are generally used instead of such schemes to satisfy semantic purists.

Class Foo (object): bar = property () @ bar.setter def bar (self, value): raise AttributeErrorFoo (). Bar = 'shit' # = > throw AttributeError exception

In this way, when you want to write properties in internal access, you will be forced to change to this keyboard-damaged way of writing: self.__dict__ ['bar'] =' blah'. So in real life, people often start with an underscore to express private attributes, and then define a getter that removes the underscore to provide read-only access.

+ 1 for Ruby

So far, I can summarize one of the reasons why I prefer Ruby:

Make a clear distinction between internal and external access to attributes, and external direct access is not provided by default. And the syntax of both access methods is not difficult to write. Developers are encouraged to consider encapsulation when designing. The usual way of Python is to underline private attributes, which will inevitably increase the amount of code.

Next, if we continue to write to introduce many key issues of the object model, I am afraid it will be marked TL;DR. So let's stop here first.

In the future, the method definition of per-instance will be introduced when talking about method parsing, thus destroying this loose description.

But you can't disturb the attribute proprietary dictionary by customizing the return value of _ _ dict__. Yes, there are a lot of out-of-line things that can be done with the ability of metaprogramming in both languages. This article can only be discussed on the assumption that developers will not actively misbehave.

Of course, you can use instance_variable_ {get,set,s} and other methods to access. See another footnote for reasons not to talk about it.

The object class itself does not define _ _ dict__, but there is no example. So although an empty New Style Class class Foo (object): pass is a direct subclass of object, the behavior of the instances of the two classes is quite different.

At this point, I believe you have a deeper understanding of "what is the difference between Ruby and Python object systems". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.