Io Language: Object System

Introduction

Continuing to write about io, it is absolutely necessary to stop separately on the device object system of this marvelous language. The main problem is that even if you “know” the PLO, the situation may well arise that you simply won’t understand how it works in io. Now, for some reason, the OOP model implies the Java model, most often. C ++ cannot be called an object-oriented language, because it is a language that supports the OO paradigm, but this is not its main paradigm. Java is more suited to the proud title of the Kommersant-OOP language, but the trouble is, the OOP dictated by the Java-like languages ​​is rather perverted. Initially, the principles of OOP originated in Smalltalk, and there everything looked a little different, objects communicated with each other not by calling methods, but by sending messages to each other, it is still strange to me why they left this model, because such a construction allows you to enter transparent parallelism in the tongue without crutches. Look at the current cool parallel languages, the same Erlang for example, everything is done through messages. Again, heaped gardens of RPC, COM and other dbus'a. But how it all began well.

Prototype OOP

We somehow got used to the fact that the PLO is built on classes. A class is a type description, an object is an instance of a class. In general, such a model has proven itself very well in the difficult task of separating logic and data, however it introduced additional confusion in the programs. You need to keep in mind all instances of the class, as well as the class itself. The question is, of course, controversial, and I don’t want to run into the classical “class-object” model, but I still want to talk about the advantages of prototypes.

We look at the prototypes, in a nutshell I described the structure in the first article , but let me remind you just in case. The prototypical nature of the language lies in the fact that there are absolutely no such concepts as a class, an instance of a class, etc. associated with the separation of the type declaration and data, in io there are only objects. An object always has its instance (how will it be in Russian?), You can get a new object by cloning the old one and changing its properties, adding / removing the necessary slots from it. Thus, we immediately kill a whole school of rodents: we have an active object, the properties / methods of which are available for use and it is also a prototype (“class declaration”) for its descendants. Very remotely (well, oh-oh-very remotely) such a structure resembles static classes.
')

Objects that are always there

Immediately after launching the interpreter, several “global” objects are available to you, perhaps the most important ones here:

• Lobby
• Object

The first object stores runtime and is, so to speak, the soil under the feet of the executable code. The second is the base object for cloning, most often the first lines of the source code on io are comments “SomeObject: = Object clone”.
That is, even when you write seemingly not “object”, you still write object. For example, the code:

 <font color = "# 9acd32"> factorial </ font> <font color = "# 8fbc8f">: = </ font> <font color = "# 8b8378"> method </ font> (number,
   <font color = "# 8b8378"> if </ font> (<font color = "# 9acd32"> number </ font> <font color = "# 8fbc8f"> == </ font> 0,
     one,
     number <font color = "# 8fbc8f"> * </ font> factorial (number <font color = "# 8fbc8f"> - </ font> 1)
   )
 )
 factorial (5) <font color = "# 8b8378"> print </ font>

It does not create a factorial function at all; it creates a factorial slot in the Lobby object.
Lobby is a context object unless the context explicitly switches to another object.

Little voodoo

Objects in io are introspective, that is, you can dig in their guts as your perverted nature just wants, if you have some strange object, you can always see what it has inside ( neon cookies)!

 <font color = "# 00ff00"> Lobby </ font> <font color = "# 8b8378"> slotNames </ font> <font color = "# 8b8378"> print </ font>

This has already begun metaprogramming, the topic of a separate article, until I just mention what you can do on the fly with objects such things that are not shown in any German film.

Modularity

Maybe this is the topic of a separate article, but you should go for a run anyway. Of course, io is a modular language, otherwise it could not be simply because it could not be. Moreover, modularity in io is done in a very cool way, there are no import / include / require_once, everything is simpler. There is a certain Z_Importer module that is loaded with the interpreter into memory, as soon as you try to use any object that is not included in the lexical overview of the current file, this module breaks down to look for a file with the name of the object. First, in the current directory, then by library catalogs (indicated by the addSearchPath method). Suppose the Mushroom, Lenin, and Man classes from the first article are in separate files. How to feed a man?

 Mushroom <font color = "# cd5c5c"> // Got a Mushroom from Mushroom.io
 </ font> Lenin <font color = "# cd5c5c"> // Get Vladimirilich from Lenin.io
 </ font> Man <font color = "# cd5c5c"> // Got Man From Man.io
 </ font>
 Man eat (Mushroom)
 Man state println

In my opinion, this is the most Zen importer I've ever seen (:

Well, all, perhaps

It seems that this is all you need to know about the io object model, the main thing to remember about messages, but that's another story (:

Links

If someone is interested in what, where, when and how, you can read the reference on io: http://iolanguage.com/scm/git/checkout/Io/docs/IoReference.html
And yesterday, we nakolbasili Russian-speaking irc channel about io: # io-ru @ FreeNode, waiting for those interested (:

PS You have here, by the way, one of the io experts sits in the downsides (And the developer StrokeDB is also catching up) - oleganza , I want to ask him to correct me or add me if I made a mistake somewhere or missed something .

(From my blog )