Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces
On Thu, Feb 1, 2018 at 11:52 AM, Chris Hopkins 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+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.
Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces
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 > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces
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 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 >> 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+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.
Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces
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 > 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
>>> 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.
Re: [go-nuts] Re: GOTCHA: Just when you think you understand interfaces
On Mon, Feb 5, 2018 at 1:13 PM, Chris Hopkins 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 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
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
>
