>
> This seems deeply insightful to me.
Thanks Michael.
It's not just maps, slices, append, and make. Every single operator could
> be considered too to be "generic" because each operates on an indefinite
> number of types.
> But Go gains much from the special-case syntax and semantics associated
> with each of these language features, IMHO. I'm sure one could make a
> language where maps, slices, pointers, etc were all just generic types and
> operations. I'm sure there are many such languages already.
Focusing on the collection side of generics, other languages allow
specifying a method for each operator but in Go you can’t use
==>><<+-<>!^/*!= operators on the collection types. I do agree that the
collection specifics are worthwhile, and they are surprisingly orthogonal:
Array:
- cannot be nil
Slice:
- reslice
- append
- cap
- make(T, len, optional cap)
Map:
- “has” check
- delete
- map indexing
- key, value range
- make(T, optional cap)
Array/Slice:
- index get
- index set
- index, value range
Slice/Map
- can be nil
Array/Slice/Map:
- len
- new
Swift for example has a solution that avoids code-bloat to some degree
> (https://www.youtube.com/watch?v=ctS8FzqcRug).
I haven't watched the whole talk yet but a consideration for Go is that
inheritance isn't used for most standard library types. Perhaps generic
collections would implement the range interface that has a specification
shortcut for use in for range, but there's no inheritable collection type.
Matt
On Tuesday, February 20, 2018 at 8:24:44 AM UTC-6, Egon wrote:
>
> 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.
