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.
