>
> we should have a tool that, given a contract body, produces a minimal
> contract body that expresses the same contract.
And run it on save, like gofmt. Or just make it part of gofmt.
On Thursday, September 6, 2018 at 4:22:34 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Sep 5, 2018 at
On Mon, Sep 10, 2018 at 5:32 AM, komuW wrote:
>
> On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote:
>>
>> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips wrote:
>> > Interesting idea, but has the Go team expressed interest in creating
>> > such a tool?
>>
>> Yes, I think it's
Personally, I'm not afraid of writing contracts manually. I suspect that in
the vast majority of the cases the contract will be clear and pretty
trivial. In fact, I think it could be a productive part of the design
process to consider what your generic function minimally needs and write
the
Good point. We will definitely want a warning before inadvertently
changing the contract...
On Friday, 7 September 2018 10:58:51 UTC-4, Tristan Colgate wrote:
>
> You lose the ability to see changes of contract in your diff (which I
> think is the thing I most want).
>
>
> On Fri, 7 Sep 2018
On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote:
>
> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips > wrote:
> > Interesting idea, but has the Go team expressed interest in creating
> such a tool?
>
> Yes, I think it's become clear that we should have a tool that, given
On Tuesday, September 4, 2018 at 11:49:23 AM UTC-5, rog wrote:
>
> 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.
>
>
In your example, you
You lose the ability to see changes of contract in your diff (which I think
is the thing I most want).
On Fri, 7 Sep 2018 at 15:56 Robert Johnstone
wrote:
> Hello,
>
> This seems more like a question for tooling. It has already been
> discussed that there should be a tool to read a body and
Hello,
This seems more like a question for tooling. It has already been discussed
that there should be a tool to read a body and provide a minimised or
canonical contract. Perhaps we forgo writing the contract in code, and
rely on godoc to determine the contract for the documentation?
The
I think it worth noting that a contract also makes good documentation for
godoc. Thus a win for all users of generic libraries.
--
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,
On Thu, Sep 6, 2018 at 3:16 PM Thomas Wilde
wrote:
> Thanks for the response. I think the question then becomes: if the syntax
> in contract bodies was an unrestricted Go block, then why do I need to
> repeat my function's operations in a contract?
>
> If the syntax of contract bodies is free,
If the contract for a type is entirely inferred in order to know the
types it accepts you have to read all of its code, every line. The
contract let's you boil that down to the salient points so you can
read line a few lines instead of a few hundred or a few thousand.
On Thu, Sep 6, 2018 at 3:15
Thanks for the response. I think the question then becomes: if the syntax
in contract bodies was an unrestricted Go block, then why do I need to
repeat my function's operations in a contract?
If the syntax of contract bodies is free, then the Go compiler could easily
deduce all my constraints
On Tue, Sep 4, 2018 at 9:49 AM, roger peppe wrote:
>
> 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
On Tue, Sep 4, 2018 at 9:17 AM, roger peppe wrote:
>
> 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
>
On Tue, Sep 4, 2018 at 7:41 AM, thwd wrote:
>
> From the draft proposal I gather two open questions:
> - How free or restricted should contract bodies be?
I believe it's useful to have contract bodies simply be arbitrary
function bodies, as the current design draft suggests. This is
because I
On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips wrote:
> Interesting idea, but has the Go team expressed interest in creating such a
> tool?
Yes, I think it's become clear that we should have a tool that, given
a contract body, produces a minimal contract body that expresses the
same contract.
Is that the go team's job, though? It's about go and automatically inferring duck types, so surely we should really be asking DuckDuckGo.Sam
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving
Interesting idea, but has the Go team expressed interest in creating such a
tool?
--
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
One thing that has been occurring to me on this is that it is probably
reasonably practical to have a tool infer and update the contracts. The
tool could limit itself to a restricted set of statements, without the spec
needing to actually limit them directly.
On Wed, 5 Sep 2018 at 09:17 thwd
If you can't use operations not explicitly stated in a contract: the more
reason to copy-paste a function body into a contract.
What I mean by implicit constraints is what the draft calls "implied
constraints".
--
You received this message because you are subscribed to the Google Groups
On 4 September 2018 at 17:53, Tristan Colgate 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
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, wrote:
> On 4 September 2018 at 17:30, Tristan Colgate wrote:
> > This would disallow contracts on presence
On 4 September 2018 at 17:30, Tristan Colgate 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
This would disallow contracts on presence and type of fields right?
The existing design permits them, and disallowing them feels a little
arbitrary.
On Tue, 4 Sep 2018, 17:17 roger peppe, wrote:
> On 4 September 2018 at 15:41, thwd wrote:
> > From the draft proposal I gather two open
On 4 September 2018 at 15:41, thwd 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
>
>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
26 matches
Mail list logo
