> Javascript is an incredibly popular language with non-inheritance OOP. Or, at least, no inheritance at the type-level (so either way, invalidating your statement that OOP is about type-hierarchies). This is debatable but JS is a non-OOP language. And yet if you wonder, there is no definition of what OOP language is. Give it any, I don't mind. But it seems to most of us it's quite clear (by major examples like C++ or Java) until we start arguing just for arguing.
> Repetition does not make a false statement true. Instead of copy-pasting yourself, it would be prudent to cite sources. For example, is there any text book that agrees with your definition of OOP? What exactly you disagree on? I will copy and paste once again for your convenience =) 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. You disagree on a statement that composition is not inheritance? Or that inheritance implies type hierarchy and vise versa? Maybe you disagree with Rob Pike who made statements quite similar to what I said regarding composition in his quote I given above? Or just arguing for arguing? I just don't understand your pathos here. > One thing that is conspicuously absent from this quote, of course, is the term "Object oriented programming" (or even just "Object"). FTR, if you quote Rob Pike, you should also be aware that he has always staunchly defended the stance that Go is an OOP language: That's ridiculous. There is a question in FAQ. And answer you are aware of, which says Go is not OOP, which Rop Pike for sure aware of as well. And his wording in that video means not how you trying to interpret. > But either way, if you don't mind me asking: What exactly does any of this have to do with generics? Good question, ask Alex Besogonov, because he started this arguing that Go has classes (opponent meant he doesn't want making Go like C++/Java). пт, 1 янв. 2021 г. в 05:16, Axel Wagner <axel.wagner...@googlemail.com>: > On Fri, Jan 1, 2021 at 1:23 AM Space A. <reexist...@gmail.com> wrote: > >> > 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. >> > > Javascript is an incredibly popular language with non-inheritance OOP. Or, > at least, no inheritance at the type-level (so either way, invalidating > your statement that OOP is about type-hierarchies). > > 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. >> > > Repetition does not make a false statement true. Instead of copy-pasting > yourself, it would be prudent to cite sources. For example, is there any > text book that agrees with your definition of OOP? > > 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. >>> >> > One thing that is conspicuously absent from this quote, of course, is the > term "Object oriented programming" (or even just "Object"). FTR, if you > quote Rob Pike, you should also be aware that he has always staunchly > defended the stance that Go is an OOP language: > https://www.youtube.com/watch?t=750&v=rKnDgT73v8s > > But either way, if you don't mind me asking: What exactly does any of this > have to do with generics? > > >> 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 >> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTd4%3DiPTtyBRhFW-aQFoEMd0jsVzrSUhTb2PtLyMWKxHiQ%40mail.gmail.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/CADKwOTcd%2Bm49WKzre_qdEP-HhcqzMOnTZR%2Bbcx_aqJiBJt2deg%40mail.gmail.com.
