On 4 September 2018 at 17:53, Tristan Colgate <[email protected]> wrote:
> Without though, people maybe encouraged to create getters and setters,which
> is very un-Go.
> Contracts can match a method explicitly if needed.
Getters and setters are only un-Go if they're used as a matter of
course for field values, I think.
We already have this issue with interfaces - we don't allow an
interface type to specify a field - interfaces only allow methods.
By allowing a contract to specify fields, we preclude a wrapper type
from adapting some other type to fit the same contract.
FWIW the Counters example in the design doc is trivially implementable
with interfaces, so I haven't yet seen decent motivation for this.
cheers,
rog.
>
>
> On Tue, 4 Sep 2018, 17:49 roger peppe, <[email protected]> wrote:
>>
>> On 4 September 2018 at 17:30, Tristan Colgate <[email protected]> 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, <[email protected]> wrote:
>> >>
>> >> On 4 September 2018 at 15:41, thwd <[email protected]> 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 [email protected].
>> >> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
