Perhaps I'm dense but I'm not sure I understand the author's point.
In C# I could easily write:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
public class Employee : Person // Employee inherits from Person
{
public string Company { get; set; }
}
Whereas in Go I might have to do this for "data embedding":
type Person struct {
Name string
Age int
}
type Employee struct {
Person // This is embedding Person struct in Employee
Company string
}
There's nothing stopping me from doing that in C#.
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
public class Employee
{
public Person person { get; set; }
public string Company { get; set; }
}
> I do think it's important for a programming language to separate these aspects from classical inheritance itself
The point is that the Golang version is closer to this:
interface IPerson {
public string Name { get; set; }
public int Age { get; set; }
}
public class Person : IPerson
{
public string Name { get; set; }
public int Age { get; set; }
}
public class Employee : IPerson
{
private Person _person;
public string Name {
get { return _person.Name; }
set { _person.Name = value; }
}
public int Age {
get { return _person.Age; }
set { _person.Age = value; }
}
public string Company { get; set; }
}
Employee conforms to the same interfaces as Person, but achieves this via delegation (the famous "favour composition over inheritance" thing)
What advantages does the Golang version have over inheritance?
Please, note I don't dispute the "prefer composition over inheritance" thing. In fact, I heartily agree with it.
But in this specific case, where every sinle detail of Person is publicly exposed in Employee (no pun intended), I don't see a material difference. If anything, the example uses composition as a tool to implement inheritance on top of.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." ~ Alan Kay
"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be." ~ Alan Kay
The antithesis of OOP is exposing the name and age of a Person to the greater system at large.
Bringing up Alan Kay's definition of OOP is approximately worthless when it comes to discussions of mainstream OOP. Yes, Erlang is "more OOP" than Java by Kay's definition. But that ship has sailed. People will (justifiably) look at you funny if you claim your functional language is OO, and when asked to name an Object Oriented language will say C#, Java, or maybe C++.
That definition is dead. Wish it well, then bid it farewell. "OOP" means "Java" and we can just call Erlang and co "Agent Model".
I think reread the first paragraph about Go embeddings and method promotion to get a better idea of what he means by embedding. It sounds more record extension, so your C# example doesn't have the property he's talking about.
This is correct. The last example of adding a Person property to Employee isn’t the same as Go’s struct embedding where Employee gets the fields and structure of Person.
In C# I could easily write:
Whereas in Go I might have to do this for "data embedding": There's nothing stopping me from doing that in C#. > I do think it's important for a programming language to separate these aspects from classical inheritance itself...they are already separated?