search

spekary / gopp

A go preprocessor that adds some object-oriented shortcuts to the language.
MIT License
1 stars 0 forks source link

This would make go being yet another OO language #6

Open mperlick opened 7 years ago

mperlick commented 7 years ago

Sorry, if this is not the right place for my comment. But I didn't find a wiki for this project. So I write my comment as a issue:

As far as I understand "go" there is deliberately no such concept as you suggest. In "normal" OO languages (C++, Java, ...) the concept of inheritance does two different things: 1.: Structural extension of data; 2.: Define and/or change behavior. All this with one language concept! In go this is strictly separated and I think this is a centerpiece of large code-base being more maintainable. If you couple both concepts in "go" IMHO you will end up with yet another "normal" OO language.

spekary commented 7 years ago

Thank you for your comments. I appreciate your interest in this for sure.

Yes, I get what you are saying. A couple of thoughts:

Go will not be "just another OO language". Even if it had this OO ability, it has enough other unique capabilities and benefits, that it will stand on its own.

I agree this is by design, but its kind of an arrogant premise. I have worked on large OO projects that were quite successful and maintainable. This premise that all unmaintanable code is caused by virtual inheritance, or that GO is somehow going to fix the world by preventing this kind of design pattern is silly. Unfortunately, it does have real affects. When I glance around the GO community, there are some that bemoan the lack of large open-source projects. There are a few out there, but not many. I think the reality is that this lack of ability in GO is actually hampering larger code bases from forming, rather than encouraging it.

Anyway, this gopp project is a demonstration that this design pattern is still achieavable given the current GO language. Its a little ugly in getting there, but it works. Its kind of like the early days when C++ was implemented using a precompiler that converted it into C. The GO language could help a lot by simply offering an easier way to do this.

From a higher level view, the problem of unmaintainable code bases is one of priorities, organization and communication between the members of the team. I don't see it as a language problem. Virtual inheritance allows teams to create layers of functionality. It lets framwork creators to specify where implementors add their code, but it also allows implementors to override frameworks in particulary ways that the framework makers did not expect. Perhaps there is a bug, or an implementor wants to expand the framework in new ways. Inheritance makes this kind of change easy, and provides a migration path to moving code from implementation into more general purpose code. I find the Interface only approach of GO much more difficult to achieve that kind of work flow, as the framework makers have to guess what are all the possible ways implementors might want to use the code. But perhaps someone else knows a better way?

spekary commented 7 years ago

Here is another example of how GO works against itself in large projects: it can't handle circular imports. So two packages cannot refer to each other. This is a basic computer science structure, called a double-link. Its also a basic human relationship, called a "partnership". GO allows dependencies, but prevents partnerships between packages. The only way around this is to either join the two packages, defeating the organizational benefits of splitting them, or having them communicate through interfaces that are part of a 3rd package that the two original packages refer to, which is a royal pain, and just adds more difficulty to delineating who owns what.