In first example Value can not do Less, its Entry, Entry has not been
defined yet, its nothing.
Unless you introduce a Lesser interface and specify Node<$Entry:Lesser>
Given that specific example this notation looks pretty heavy, <node.$Entry>
and even worse if d that be <node.$Entry:Lesser>
As this is all scoped into a type definition, why this prefix "node." ?
Also there s node everywhere, its confusing.
I m confused by the second example, the package declaration seems to
declare what should be parametric.
It looks weird to import from another package.
Entry generic type is an interface, isn it ?
apart from this, why is side a double pointer ?....
On Friday, August 25, 2017 at 10:11:11 AM UTC+2, Egon wrote:
>
> package tree
>
> type Node<$Entry> struct {
> Value $Entry
> Left *Node<$Entry>
> Right *Node<$Entry>
> }
>
> func (node *Node) Insert(value node.$Entry) {
> var side **Node<node.$Entry>
> if node.Value.Less(value) {
> side = &node.Right
> } else {
> side = &node.Left
> }
>
> if *side == nil {
> *side = &Node<node.$Entry>{Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
> --
>
> package tree<Entry>
>
> type Entry generic {
> Less(Entry) bool
> }
>
> type Node struct {
> Value Entry
> Left *Node
> Right *Node
> }
>
> func (node *Node) Insert(value Entry) {
> var side *Node
> if node.Value.Less(value) {
> side = &node.Right
> } else {
> side = &node.Left
> }
>
> if *side == nil {
> *side = &Node{Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
>
> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>
>> Why would you put generics on a method ?
>>
>> The syntax you demonstrate is horrible, indeed.
>>
>> what if generics are type related
>>
>> type notFinal struct {
>> p1 <T1>
>> p2 <T2>
>> }
>>
>> func (n notFinal) whatever(in <T1>) string {
>> return fmt.Sprintf(in) // anything to interface{}, works.
>> }
>>
>> type Final notFinal<int, string>
>>
>> Final.whatever(1) // "1"
>>
>> //notFinal not instantiable, not type assertable
>>
>>
>>
>> Or func related
>>
>> type notFinal func(in <T1>) string
>>
>> func Final notFinal<int>
>>
>> Final(1) // "1"
>>
>>
>> That said, ultimately, the more the syntax is parametrized the more
>> complex it become. when there are many func signature as you demonstrate,
>> it will get worse.
>>
>> Named type might help, could be vetted too ?
>>
>> Also
>> none of this is as powerful as code gen.
>> None of those examples are better than interface{}.
>>
>> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>>
>>> A lot of people like Go because code is very readable even for beginners.
>>>
>>> func f(x, y int)
>>>
>>> f is a function that receives x and y as int parameters, returning
>>> nothing. Simple enough.
>>>
>>> func f(x, y int) int
>>>
>>> f is a function that receives x and y as int parameters, returning yet
>>> another int. Fine.
>>>
>>> func f(x, y int) (z int, err error)
>>>
>>> f is a function that receives x and y as int parameters, returning two
>>> values: a first int, that we name z and an error named err. A little bit
>>> weird, but ok.
>>>
>>> func (r MyType) f(x, y int) (z int, err error)
>>>
>>> f is a method for a value of type MyType, henceforth named r, that
>>> receives x and y as int parameters, returning two values: a first int, that
>>> we name z and an error named err. Definitely not so simple.
>>>
>>> <genType1, genType2> func (r genType1) f(x, y genType2) (z getType2, err
>>> error)
>>>
>>> You must be kidding. STOP RIGHT THERE!
>>>
>>>
--
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.
