Quoting Burak Serdar (2018-10-19 15:13:20)
> Without operator overloading:
>
> type X interface {
> implements <
> }
>
> means that you want a primitive numeric type or a string. So:
This is not quite quite correct; in Eric's proposal, it is possible to
define (for example):
```
// A Version represents a semver-style version number
type Version struct {
Major, Minor, Micro int
}
// We define a custom definition of `<` that checks which version is
// older.
func (v Version) Less(other Version) bool implements < {
switch {
case v.Major < other.Major:
return true
case v.Major > other.Major:
return false
case v.Minor < other.Minor:
return true
case v.Minor > other.Minor:
return false
default:
return v.Micro < other.Micro
}
}
```
..and then use `<` to compare Versions. By contrast, your proposal does
not make it possible to define custom notions of `<` on user defined
types.
> Another thing that motivated me to start this thread in the first
> place was imagining myself sitting late at night trying to figure out
> how to convert a huge chunk of code to a generic type, and reading
> through to figure out exactly what the contract is. With the "like"
> syntax, I could simply add "like X" to my arguments, and be done with
> it. With interfaces containing "implements", I have to write those
> interfaces and figure out exactly what I need.
With interfaces using implements, you can start off just specifying no
constraints on your generic parameters, and then follow the type errors
until you've added all of the necessary methods.
While pinning down exactly what the contract needs to be is a bit of
extra up-front work, I think it is important to keep these contracts
clear; one of my biggest concerns with the draft design is that I do not
believe it encourages thinking about intent.
> With contracts, I imagine someone would come up with a tool to build
> that from the source if it comes to that.
This could also be built for the interface version; just see what
methods are called and put them in an interface that the parameter must
implement.
Quoting Eric S. Raymond (2018-10-19 16:03:02)
> Both classes want to be selected by a field "name". It's annoying that
> I can't declare an interface that says "has a field 'name'" and instead
> have to declare a getter function with no other point besides sliding
> around that restriction.
>
> But precisely because this could easily be patched into interfaces,
> I think it's not much of an argument for your plan.
To spell out how this would for anyone who doesn't immediately see the
design, you could e.g. extend interfaces to be able to have fields like
so:
type HasName interface {
Name string
}
To implement this, a type would have to have a field Name with the type
string.
I am neutral-to-against doing this, as normally when abstracting over
something, it is a behavior, not a field. But if being able to specify
"must have this field," is deemed necessary, I agree this is the way to
do it.
--
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.
