Thought about this today, and although your argument is valid for the case
where the function signature contains Node (like this)
func (e E) Less(e2 Node) bool {
return e.value < e2.value
}
the function signature presents a different type with Element
func (e E) Less(e2 Element) bool {
return e.value < e2.value
}
so the type-checker shouldn't allow a different implementation of Node to
be passed into the function.
The question was more about using the function signature to constrain the
type, instead of assuming that the contract inside an interface is the only
way to constrain it. I agree however, that this would make explaining
interfaces more complicated, and was more curiosity than an issue.
On Wednesday, February 8, 2017 at 2:40:49 AM UTC-5, Jesse McNelis wrote:
>
> On Wed, Feb 8, 2017 at 5:41 PM, <aind...@gmail.com <javascript:>> wrote:
> > satisfies the interface, but requires a type assertion. However,
> >
> > func (e E) Less(e2 Element) bool {
> > return e.value < e2.value
> > }
> >
>
> If this version of Less() satisfied the interface Node what happens
> when I pass something that isn't an Element but also satisfies the
> Node interface?
> It gets very complicated to explain what the rules would be in the
> various possible edge cases.
>
--
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.
