On Monday, 19 February 2018 12:06:09 UTC+2, RickyS wrote: > > Back when I first learned about the diamond problem with multiple > inheritance, I've known we need someone to invent the next and better thing > after inheritance. I do hope somebody smarter than me is somewhere trying. > Or even has succeeded. >
There are many problems that are difficult in abstract, but easier in practice. As such I think that best solution to the diamond problem is not to use inheritance. The question becomes: what to do instead and which problems does the "alternative solutions" have. There are of course many known alternative solutions already: traits, Entity-Component-System, BOT architecture or DCI. The problem is not "inheritance diamond", it's usually something else... for example, how to clearly and succinctly model complex entities in a game. When we just try to figure out the most flexible approach we may miss the mark by providing sufficient flexibility, but not the clarity in the problems. > And back when I first learned about the code bloat that could result from > C++ generics/templates, I've known we need somebody invent the next and > better thing after "Generators". Generators, by the way, first appeared in > the 1950's, when they were considered a failure. > > It's been decades, and I'm still waiting. I would like to believe the Go > Authors are waiting for better solutions. Or even inventing them. > Swift for example has a solution that avoids code-bloat to some degree (https://www.youtube.com/watch?v=ctS8FzqcRug). Of course, this comes at the cost of performance. In that sense, there is progress, although it is slow. > N.B. All praise to the Go Authors for upgrading past the massive > inefficiency of #include files. Also for many other things. > > Well built software is easily modified. Easily-modified software is > modified and modified until it is incomprehensible and no longer easily > modified. Progress gets slower and slower and slower. Until it stops > entirely. Having the maturity and character to refrain from second-best > modifications is rare and wonderful. The ideas behind generics and > inheritance are basically: "Do this thing just like that other thing, > except differently here and here". Re-use code and concepts. I can feel the > passion for this goal. I have felt the sand in my gears as I drive the new > machine with 256 levers and switches. > > > *On Friday, February 16, 2018 at 8:25:35 AM UTC+2, dc0d wrote:* >> >> *All forms of generics that I would love to have in Go: ...* >> > > -- 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. For more options, visit https://groups.google.com/d/optout.
