Without though, people maybe encouraged to create getters and setters,which
is very un-Go.
Contracts can match a method explicitly if needed.
On Tue, 4 Sep 2018, 17:49 roger peppe, <rogpe...@gmail.com> wrote:
> On 4 September 2018 at 17:30, Tristan Colgate <tcolg...@gmail.com> wrote:
> > This would disallow contracts on presence and type of fields right?
> > The existing design permits them, and disallowing them feels a little
> > arbitrary.
>
> It would, yes. But on balance, I think that the presence of selectors
> in contracts makes for them harder to understand. For example, the
> rather arbitrary rules about value methods go away if you don't allow
> selectors. The ambiguity between a field selector and a method
> selector goes away too. For example, the Stringer contract in the
> design doc purports to check that there's a method named String, which
> it does not - it could be a function-valued field instead.
>
> So if you've written something like this:
>
> func FastString(type T stringer)(x T) string {
> switch x.(type) {
> case myType:
> return x.String()
> default:
> // Slow path: fall back to fmt.
> return fmt.Sprint(x)
> }
> }
>
> you might expect that fmt.Sprint will call the String method that's
> defined on x, but that's not guaranteed.
>
> The selector operation does so much work in Go that it's hard to
> classify it as a single operation, and I think that disallowing it
> lets values focus more on behaviour and less on appearance, as
> interfaces do.
>
> >
> > On Tue, 4 Sep 2018, 17:17 roger peppe, <rogpe...@gmail.com> wrote:
> >>
> >> On 4 September 2018 at 15:41, thwd <sedeveloper...@gmail.com> wrote:
> >> > From the draft proposal I gather two open questions:
> >> > - How free or restricted should contract bodies be?
> >> > - How many implicit constraints can be inferred from usage?
> >> >
> >> > If too much syntax is allowed in contract bodies and no implicit
> >> > constraints
> >> > are gathered:
> >> > people will copy and paste function bodies into contracts to cover all
> >> > constraints.
> >> >
> >> > If only restricted syntax is allowed in contract bodies and a lot of
> >> > implicit constraints are gathered:
> >> > people will write empty contracts and hope for the compiler to pick up
> >> > on
> >> > all the constraints.
> >> >
> >> > These two questions are related.
> >>
> >> As I understand it, if a contract doesn't allow it, you won't be able to
> >> do it.
> >> That is, the contract is scanned for "operations" (however they might be
> >> defined), and then it will be a compiler error if a function uses an
> >> operation
> >> not permitted in the contract.
> >>
> >> An empty contract body permits no operations other than those available
> >> on every Go value (copying, taking address of, passing as a parameter,
> >> etc).
> >>
> >> So I'm not entirely sure what you mean by "implicit constraints".
> >>
> >> That said, it is my opinion that it is very hard to read an arbitrary
> >> constraint
> >> body and infer the set of possible operations that can be performed.
> >> It's not that much easier to look at it and work out what types might
> >> satisfy
> >> the contract either.
> >>
> >> My suggestion (that I've written up here:
> >> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
> >> that, at least to start with, we allow only a very restricted set of
> >> contract bodies.
> >>
> >> Specifically, in my suggestion, every statement in a contract body
> >> must consist of exactly one expression.
> >> Identifiers in the expression can only reference types or the
> >> contract's parameters.
> >> The expression must reference at least one of the contract's type
> >> parameters.
> >> The expression must exactly one of:
> >> - any unary or binary operator (but not a field or method selector)
> >> - a function invocation
> >> - a type conversion
> >> - an index expression
> >>
> >> Intuitively I'd like a single statement in the expression to specify
> >> exactly a single operation which should be clear from the operands of
> >> the expression.
> >>
> >> Thus if you look down the contract and you don't see the operation
> >> you're looking for, then you can't do it.
> >>
> >> cheers,
> >> rog.
> >>
> >> --
> >> 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.
