Well, the first allows one Less per package, the second allows one per 
type. Since I tend to have multiple types in a package I find that more 
readable.

Anyway, I finally fixed the problem with mixture of reflect and type 
assertion
      val := reflect.ValueOf(b)
      if val.Kind() == reflect.Slice {
        leng = val.Len() // outer length
        for i := 0; i < leng; i++ {
          v := val.Index(i)
          if v.Kind() == reflect.Slice {
            sz = v.Len() // inner length
            for j := 0; j < sz; j++ {
              vv := v.Index(j)
                            if m, ok := vv.Interface().(Useable); ok {
                n, ok := 
reflect.ValueOf(a).Index(i).Index(j).Interface().(Useable)
                if !ok {
                  log.Fatal("a is not the same type as b")
                }
                good = m.Equal(n)
              } else {
                log.Fatal("Candidate cannot be converted to a Usable type")
              }
            }
          }
        }
      }


Yeah it's a bit ugly and I'm working on something better, but the immediate 
issue is closed for now, so thanks everyone for the kick in the right 
direction.

Regards

Chris


On Thursday, 1 February 2018 18:55:27 UTC, Axel Wagner wrote:
>
> I don't really see the difference in writing
> func Less(a, b *T) bool
> and
> func (a *T) Less(b *T) bool
> convenience wise - except that the latter requires the name to be exported 
> and doesn't allow using a function literal (so, yeah, the latter actually 
> seems significantly *less* convenient).
>
> On Thu, Feb 1, 2018 at 7:51 PM, Chris Hopkins <cbeho...@gmail.com 
> <javascript:>> wrote:
>
>> No, was hoping to use the interface (It's the only reason I defined it) 
>> to test if two items are equal.
>> I guess I could enforce that you have to supply the equals function like 
>> the sort interface does. I was just hoping for more.
>>
>> I'll have a rethink next time I have time.
>>
>> Thanks
>>
>> On Thursday, 1 February 2018 18:46:09 UTC, Axel Wagner wrote:
>>>
>>> On Thu, Feb 1, 2018 at 11:52 AM, Chris Hopkins <cbeho...@gmail.com> 
>>> wrote:
>>>
>>>> Yeah, so having played with this. It seems that this is going to take 
>>>> some judicious use of reflect if I'm to stand any chance of maintaining a 
>>>> flexible API, which I really hoped to avoid.
>>>>
>>>
>>> I'm 99% sure that you don't have to use reflect at all. You only have to 
>>> swap elements around, that's kind of what sort.Interface was made for. It 
>>> already comes with implementations for slices of common datatypes and you 
>>> can make a function that works on arbitrary slices with less than ten lines 
>>> of reflect code.
>>>
>>> Like, I *really* don't understand your problem.
>>>  
>>>
>>>> I had assumed that the point of interfaces was to avoid this. I guess 
>>>> from a high level I don't see why a slice of type is really that different 
>>>> from a type. But I have never written a compiler so I'm sure that it's way 
>>>> more complex than it seems. :-)
>>>>
>>>> Thanks for the help.
>>>> Chris
>>>>
>>>>
>>>> On Thursday, 1 February 2018 00:42:04 UTC, simon place wrote:
>>>>>
>>>>> also notice, if you haven’t encountered it, this makes []interfaces a 
>>>>> bit awkward to handle with ellipsis functions...
>>>>>
>>>>> https://play.golang.org/p/JWuc4jt2uSP
>>>>>
>>>>> what i do is this; 
>>>>>
>>>>> https://play.golang.org/p/O9Q4K_vXlul
>>>>>
>>>>> but you will need a convert for all combinations of interfaces and 
>>>>> ellipsis functions you have!
>>>>>
>>>>> from what i understand ellipsis functions are implemented simply as 
>>>>> auto-magic slices, rather than expanded out, so the function doesn’t 
>>>>> apply 
>>>>> the interface wrapping like with individual parameters.
>>>>>
>>>>> -- 
>>>> 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...@googlegroups.com <javascript:>.
>> 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.

Reply via email to