GO: An OO Core with Functional Abilities.md

GO: An OO Core with Functional Abilities.md

Why does OO weaken encapsulation?

class Something:
    def __init__(x, y, z):
        self.x = x
        self.y = y
        self.z = z
        
    def some_method():
        pass

a = Something()
a.x
a.some_method

Python is of course an OO language. Does it provide good encapsulation? Everything in Python is public. There is no information hidding. Python does not only weaken the information hidding, it takes away information hidding.

In main stream OO langs like Python, Java, C++, the method/interface of a module/class/pkg are bundled with data structure's details (properties, fields).

The user is not only able to access them at runtime, but also from source code. With private/protected key word in Java and C++, users are not able to access some info at runtime, but still able to see them in source code, unless you distribute a binary.

C, on the other hand, can have perfect encapsulation by not including any inner implementations in .h. You can't do that with C++ because of some compilation/linking logic. (templates are in .h, class definitions are in .h)

Conclusion

Encalpusalation is not the vital feature of OO, not even a required property of OO.

Why Class is not required in OO?

Prototypes: JavaScript, Python are all prototype style OO. Python has a better class style syntax and semantics, but still, CPython implementation is prototype based. I also believe the Ruby has prototype flavored OO, very similar to Python.

OO is about Polymorphism

Polymorphism is the ability to use different implementations of the same interface in different scopes, through the proper use of function pointers.

What's why a OO lang has great modeling power.

It usually involves allocating instances in the heap so that the instance out lives the life cycle of the function of which it is called on.

And Java still don't have value class? (not sure)

Inheritance

Inheritance is just the ability to redefine the same interface in a sub scope.

Prototype vs Class

Prototype binds a unique scope to individual instances of a type.

Class binds a unique scope to each type.

---

Go and OO

First, we need to know

type X struct {}
func (x X) Method() {}
x = X{}
x.Method()

It's worth to know that GO allows a method receiver to be an concrete value instead of a pointer. Many OO langs don't allow that, or at least it's unconventional.

Note: GO only has pass by value. There is no pass by reference support in GO. Because of that, people may use "pass by reference" to mean "pass a pointer's value". But, they are really 2 different concepts, linguistically speaking.

We also need to know

type X interface { method() }

func f1(x X) {}

type Y struct {}
func (y Y) method() {}

f1(Y{})

Interfaces in Go are implicitely satisfied. This is my favorite GO language level feature. It removes lots of source code level coupling and unnecessary dependencies.