There are some contracts in the draft design that can’t be expressed with the
“implements” syntax as it stands. Some would be fairly simple syntax
extensions, but others describe the relationship between two types rather than
just the operations on a single type. No extension of interfaces (except
perhaps generic interfaces with mutually-referential type parameters) can
handle those.
The one called convertible is an example of one that would require a fairly
trivial extension: adding a way to declare that a method implements a type
conversion.
For an example of the other kind, take G from the graph example. I don’t think
any of the alternate proposals can handle that situation (at least not nearly
as succinctly):
contract G(n Node, e Edge) {
var _ []Edge = n.Edges()
var from, to Node = e.Nodes()
}
Even if we give up on the ability to define relationships between types, adding
extensions for all the other operations that people will want support for will
likely take away much of the initial simplicity that makes the “implements”
syntax attractive—one trivial extension at a time. The “contract” proposal, on
the other hand, is actually a simple, powerful idea; it's working out the
implications that ties people’s brains in knots.
Andy
> On Oct 19, 2018, at 9:18 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
>
> Andy Balholm <andybalh...@gmail.com>:
>> It seems to me that what you are proposing with “implements” is not really a
>> replacement for contracts. It would do something that contracts don’t (unify
>> operators and methods), and it wouldn’t do nearly all of what contracts do
>> (clearly define what is expected of type parameters across a wide range of
>> possible operations).
>
> I don't understand the the grounds of this objection. Can you pose some cases
> you think implements couldn't cover?
> --
> <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be your
> own.
>
>
--
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.
