People may find this excellent paper “Datatype-Generic Programming” by Jeremy
Gibbons useful in this discussion. It’s 72 pages long.
https://www.cs.ox.ac.uk/jeremy.gibbons/publications/dgp.pdf
I want generics but I still don’t know if I like this go2 generics proposal. At
least as an exercise it may be worth reimplementing go1’s builtin generics
using the proposed features (not syntax but functionality). Plus standard
generic collections including things like N dim. vectors. Hopefully this
extended exercise would make it clear if the goal of making it easier to write
correct code is better met with this proposal.
> On Sep 2, 2018, at 7:50 AM, Sebastien Binet <seb.bi...@gmail.com> wrote:
>
> Hi,
>
>> On Sun, Sep 2, 2018, 12:55 haskell_mustard via golang-nuts
>> <golang-nuts@googlegroups.com> wrote:
>> I prefer seeing the contract by example over having a combination of two
>> dozens of interface names like Eq, Lesser, Adder, Muler, Convertible(x),
>> Ranger, Lener, Caper, ... that have to be mentally mapped to their actual
>> syntactic representation. This smells like taxonomy ("the lowest form of
>> academic work" ;)
>
>
> I am all for original features and perhaps indeed using interfaces in lieu of
> contracts would be better.
> And I guess I could live with a zoo of special interfaces to capture all the
> '+=', == and other special operators.
> But, as it was mentioned in the FAQ of the draft proposal, how would one
> express the need for an explicit field (name + perhaps type too) ?
>
> How would interfaces-as-contracts play out for example if I wanted to make
> sure the Image type passed to that parametric function is a struct, with a
> field Pixels that's a slice of quadruplets R, G, B, A (that hold some type of
> numerical value)
> So redoing some of the x/image/draw kernels, sans the interfaces overhead?
> And without declaring a bunch of SetFoo, SetBar and GetBar methods?
>
> -s
>
>>
>>
>>> On Sunday, 2 September 2018 10:14:48 UTC+2, Tristan Colgate wrote:
>>> It's a great read, clarified stuff for me. An approach that embraces
>>> interfaces feels preferable to me.
>>>
>>>
>>>> On Sun, 2 Sep 2018, 09:09 'Charlton Trezevant' via golang-nuts,
>>>> <golan...@googlegroups.com> wrote:
>>>> Link: [Getting specific about generics, by Emily
>>>> Maier](https://emilymaier.net/words/getting-specific-about-generics/)
>>>>
>>>> The interface-based alternative to contracts seems like such a natural
>>>> fit- It’s simple, straightforward, and pragmatic. I value those aspects of
>>>> Go’s philosophy and consider them to be features of the language, so it’s
>>>> encouraging to see a solution that suits them so well. The author also
>>>> does a great job of contextualizing the use cases and debate around
>>>> generics, which I found incredibly helpful.
>>>>
>>>> Any thoughts?
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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.
>
> --
> 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.
--
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.
