> Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to do with inheritance. It's a common feature in object-oriented programming but it's not essential. > Moreover, Go has inheritance as well (struct embedding and interface inheritance), making it a fairly typical example. The only significant difference is that Go has structural typing, instead of manually declaration of implemented interfaces.
You don't disappoint me by repeating wrong statements. As I said, OOP (if we talk about language, not a program written in OOP paradigm, because you can use ANY language for that) is all about inheritance. Period. Proof - take any major OOP language and see how it's done, what's in its heart. Secondly, and I copy-paste myself here: Classes (like in Java) vs structs (like in Go) is about inheritance vs composition, not about attaching fields and methods. Inheritance implies type hierarchy, child and parent, virtual functions, abstract and final implementations and so on so forth to keep this all of this manageable. If you don't understand what it means, please study a little bit (with all respect and blabla, I also learn all the time). Because these two approaches are different. Here is some small quote and link which I think can help: My late friend Alain Fournier once told me that he considered the lowest > form of academic work to be taxonomy. And you know what? Type hierarchies > are just taxonomy. You need to decide what piece goes in what box, every > type's parent, whether A inherits from B or B from A. Is a sortable array > an array that sorts or a sorter represented by an array? If you believe > that types address all design issues you must make that decision. > I believe that's a preposterous way to think about programming. What > matters isn't the ancestor relations between things but what they can do > for you. > > That, of course, is where interfaces come into Go. But they're part of a > bigger picture, the true Go philosophy. > If C++ and Java are about type hierarchies and the taxonomy of types, Go > is about composition. > Doug McIlroy, the eventual inventor of Unix pipes, wrote in 1964 (!): > > We should have some ways of coupling programs like garden hose--screw in > another segment when it becomes necessary to massage data in another way. > This is the way of IO also. > > That is the way of Go also. Go takes that idea and pushes it very far. It > is a language of composition and coupling. > The obvious example is the way interfaces give us the composition of > components. It doesn't matter what that thing is, if it implements method M > I can just drop it in here. > Another important example is how concurrency gives us the composition of > independently executing computations. > And there's even an unusual (and very simple) form of type composition: > embedding. > These compositional techniques are what give Go its flavor, which is > profoundly different from the flavor of C++ or Java programs. > https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html чт, 31 дек. 2020 г. в 23:27, Alex Besogonov <alex.besogo...@gmail.com>: > On Wednesday, December 30, 2020 at 12:23:35 PM UTC-8 Space A. wrote: > >> > OOP isn't specific about how inheritance is handled (or if it is even >> supported) >> Oh my... It is pure sophistic nonsense. OOP is all about inheritance. Not >> just whether you have "objects" in a language spec or not. >> > Sorry to disappoint you (actually, no, not sorry) but OOP has nothing to > do with inheritance. It's a common feature in object-oriented programming > but it's not essential. > > Moreover, Go has inheritance as well (struct embedding and interface > inheritance), making it a fairly typical example. The only significant > difference is that Go has structural typing, instead of manually > declaration of implemented interfaces. > > > But on the topic of generics, this entire thread seems alarmist. >> Generics will open a huge door for libraries to be written that will make >> our lives easier. I'm thinking specifically about data processing and >> machine learning. A lot of devs use Python right now for this which leads >> to duplication of code across languages. Complex algorithms will be able >> to be shared without hacky type conversions wrapping every function call. >> Who is "yours"? You talk about Python so just go ahead and use Python if >> it serves you, convince your team that Python is better, whatever. >> > You know that this argument can be applied to you as well? > > >> среда, 30 декабря 2020 г. в 22:46:12 UTC+3, nichol...@gmail.com: >> >>> OOP isn't specific about how inheritance is handled (or if it is even >>> supported). The basic definition is objects with fields and methods, and >>> being able to address the itself (typically using 'this' or 'self', but Go >>> is unique in that you define what to call the object). It does composition >>> differently than most languages, but the functional needs are met. >>> >>> But on the topic of generics, this entire thread seems alarmist. >>> Generics will open a huge door for libraries to be written that will make >>> our lives easier. I'm thinking specifically about data processing and >>> machine learning. A lot of devs use Python right now for this which leads >>> to duplication of code across languages. Complex algorithms will be able >>> to be shared without hacky type conversions wrapping every function call. >>> We'll be able to use things like trees as simply as we use maps or slices. >>> I don't think we'll see the language turn into the grossness that is Java >>> or C++ because of it. >>> >>> On Wednesday, December 30, 2020 at 4:27:15 AM UTC-8 Space A. wrote: >>> >>>> Go doesn't have classes and is not an OOP language. >>>> >>>> Classes (like in Java) vs structs (like in Go) is about inheritance vs >>>> composition, not about attaching fields and methods. Inheritance implies >>>> type hierarchy, child and parent, virtual functions, abstract and final >>>> implementations and so on so forth to keep this all of this manageable. >>>> >>>> >>>> >>>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: >>>> >>>>> Please, stop being so condescending to newcomers and non-professional >>>>> developers. Generics as uses by end-users will improve their experience, >>>>> not make it harder. >>>>> >>>>> (And what is this obsession with "classes"? Go has them - structs with >>>>> methods are classes). >>>>> >>>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/LEEuJPOg0oo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7b58c437-4507-4d75-b0a2-de7b0ba8b58dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADKwOTd4%3DiPTtyBRhFW-aQFoEMd0jsVzrSUhTb2PtLyMWKxHiQ%40mail.gmail.com.
