How to design a programming language (iii) what is a pit (object-oriented and exception handling)

Before all the text, I need to emphasize that I personally opposed to structure typing, so even if the content of the text "looks like" go interface, readers should not feel that I am praising go interface. What I like more is the way that Haskell and rust. Unfortunately rust and go as much as I want to shrink all the words are the shortest, the result code written to even the readability is not, the word has become a symbol. If rust the mess of pointer design and go of that kind of crap abbreviation together to kill, I will certainly like rust. Similarly, com this thing design is really too damn right, it is the best example of learning object-oriented skills, but COM in C + + under the operation up a little silly force, so many people see this thing on the AH hehe.

The last article said this time to write the class member function and the lambda thing, but I thought, or first put OO before, so the order is right.

I remember when I was in middle school, I often heard the propaganda, is object-oriented approach is very consistent with human thinking habits, so everyone like, big line, help write robust program. It's been more than 10 years now, I found that there is no such comment on the internet, but also did not like the wave of anti-C + + desperately to say that the object here is not good to abolish it-obviously people still feel that with object-oriented language is still relatively cool, otherwise there is not so many people to study, A language that is particularly useful for writing functional programming--javascript--is how to "simulate" the common operations--new, inheritance, and virtual functions in object-oriented languages.

So something as simple as an object-oriented definition should not be a hole in the syntax. So what's the pit today? Answer: It's people.

Object-oriented in dynamic type language I do not know exactly where, for this language, as long as the functional programming that part of the rest of Oo to do not, is purely a grammatical sugar problem. In a dynamic type language, the difference between a class and a lambda expression is not really.

So what does the object of the static type language look like? The first thing we have to think about is that all object-oriented languages support interface. C + + Although there is no direct support, but he has multiple inheritance, we only need to write a pure virtual class out, it can be used as interface.

Here I have to say the pure virtual class of C + + and interface this thing. Let's say we have the following C # code:

Interface ibutton{}
interface iselectablebutton:ibutton{}
interface idropdownbutton:ibutton{}
class checkbox:iselectablebutton{}
    
class Mypowerfulbutton:checkbox, Idropdownbutton
{
    // Here we only need to implement Idropdownbutton inside more than IButton that part of the function is enough.
}

Let's just look at this inheritance relationship, regardless of whether or not the GUI is really able to write. This is a simple example that can no longer be simpler. It means that I have two button interfaces, and I extend one of the things that supports another button interface from one implementation. But as you all know, my perfect gacui is C + +, so what's the problem with C + +?

#region complain.

Generally speaking in C + + with pure virtual class to replace the interface, we inherit a interface with the virtual inheritance. Why, then? Looking at the example above, Iselectablebutton inherits from Ibutton,idropdownbutton inherited from IButton. So when you write a Mypowerfulbutton, do you want the ibutton of the two interfaces to be something different? Of course it's not. So how do you get the ibutton of two interfaces pointing to the same thing? Of course it is inherited by virtual.

OK, now we have the checkbox that implements the Iselectablebutton (with IButton), and then we start writing Mypowerfulbutton. What's going to happen?

Wrong guess! The answer is, in fact, we can write, but Visual C + + (GCC or whatever you play it yourself) will give us a warning, the effect is that you idropdownbutton inside the IButton is covered by a checkbox, Again, the abstract point is that a parent class overrides a virtual function of another parent class. This has nothing to do with virtual inheritance, how you inherit will be the problem.

But this actually also cannot blame compiler, originally in other cases, the virtual function so covers nature is bad, who let C + + No interface this concept. But the GUI often encounters this kind of thing, so I have to helplessly in these places use #pragma to supress out this warning, anyway I know what I am doing.

C + + No interface complain here is over, but the things of virtual inheritance here is not finished. Let me cite one more example:

Class A
{
private:
    int i;
Public:
    A (int _i) I: (_i) {}
};
    
Class B:public Virtual A
{public
:
    B (int _i): A (_i) {}
};
    
Class C:public Virtual A
{public
:
    C (int _i): A (_i) {}
};
    
Class D:public B, public c
{public
:
    D (): B (1), C (2) {}
};