On Mon, Feb 5, 2018 at 1:13 PM, Chris Hopkins <cbehopk...@gmail.com> wrote:
> Well, the first allows one Less per package, the second allows one per
> type.
>
No, the first allows an arbitrary number of Less' per package or type and
the second one allows one per type.
You can call a function LessByName, LessByID, LessBy…. You can also use
method-expressions to transform methods into func()s. And you can use
closures, which really is what sets it apart.
But anyway.
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> 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.
>>> 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.
