Oooooh. Okay ! Yeah sorry I think my mind got stuck with the notion of
"abstract definition" of any type and did not see the concrete use they
could be subject to. I see what you mean :
https://play.golang.org/p/8P3IJElTS7d would effectively not work.
I think I didn't have the full picture of this.
So indeed I was wrong about the fact that struct fields in contracts needed
not be named since all functions using such types should know what fields
they can refer to.
Thx for the enlightenment ! :)
Le mar. 20 nov. 2018 à 16:27, Burak Serdar <bser...@ieee.org> a écrit :
> On Tue, Nov 20, 2018 at 7:59 AM Michel Levieux <m.levi...@capitaldata.fr>
> wrote:
> >
> > I'm not quite sure I understand your example .
> > According to me a contract on a structure type only defines what the
> structure type should have (aka the minimum number of fields and their
> respective types). When you define a function with a generic type, the only
> thing the compiler should check is that on such a function call, the type
> passed as parameter to it respects the given contract (in our example, this
> translates to --> "any function taking type DoubleLinkedListNode value as
> parameter should be called with a type X that has at least two fields that
> are pointer to values of type X"). The implementation you chose to adopt
> for this
> function does not matter (?).
>
> You are suggesting that a contract would be checked only when a
> generic type is instantiated. That is not the case here.
>
> A contract serves two purposes:
> 1) A generic type declared using a contract can be compiled and
> type-checked when it is declared, not when it is instantiated.
> 2) When using a generic type, the concrete types used to instantiate
> the generic type can be validated against the contracts
>
> A struct contract without field names cannot be used for #1.
>
> For #2, a contract written without field names does not really help
> the generic type user. Without names, the only way to figure out what
> the generic type requires is to look at its implementation. A contract
> is a way to announce what the generic type expects, and you can't do
> that without field names.
>
> Also: if you use interfaces instead of structs:
>
> contract doublyLinkedListNode {
> X interface {
> GetNext() *X
> GetPrev() *X
> }
> }
>
> what you are suggesting is similar to having an interface with two
> nameless functions returning *X.
>
> >
> > Le mar. 20 nov. 2018 à 15:52, Burak Serdar <bser...@ieee.org> a écrit :
> >>
> >> On Tue, Nov 20, 2018 at 7:36 AM Michel Levieux <
> m.levi...@capitaldata.fr> wrote:
> >> >
> >> > Yes, but you can just specify the concract like :
> >> >
> >> > contract doubleLinkedListNode {
> >> > X struct {
> >> > *X
> >> > *X
> >> > }
> >> > }
> >> >
> >> > which defines a type X containing at least two pointers to values of
> type X. You'd do the same currently for a function type --> func (int, int,
> string), which takes two ints in its arguments (along with a string), but
> you do not name the parameter. I think one might not forget that we're
> talking "type signature" here, and not type definition :)
> >>
> >>
> >> Something like that won't help to compile the following:
> >>
> >> func (l *DoublyLinkedList) Insert(type Node
> >> DoublyLinkedListNode)(insertBefore,newNode *Node) {
> >> if insertBefore!=nil {
> >> newNode.next=insertBefore
> >> newNode.prex=insertBefore.prev
> >> }
> >> ... etc
> >>
> >> >
> >> > Le mar. 20 nov. 2018 à 15:26, Burak Serdar <bser...@ieee.org> a
> écrit :
> >> >>
> >> >> On Tue, Nov 20, 2018 at 6:27 AM Michel Levieux <
> m.levi...@capitaldata.fr> wrote:
> >> >> >
> >> >> > I guess X is the type that is represented by the struct, the
> meaning being : "the type X is a struct that contains a field that is a
> pointer to a value of the same type".
> >> >> >
> >> >> > EDIT : I think the "next" word, which is here the name of the
> field, can even be omitted. The relevant information here is to know the
> type X contains a field of type *X, whether this field is named "next" or
> "child" or anything else does not break the viability of the expression.
> >> >>
> >> >> Name of the field cannot be omitted. For a doubly linked list, you'll
> >> >> need two of those, prev and next, and if you have a function working
> >> >> on a node satisfying that contract, it has to access both of those
> >> >> fields.
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> >
> >> >> > Le mar. 20 nov. 2018 à 12:38, komuW <komu...@gmail.com> a écrit :
> >> >> >>>
> >> >> >>> A contract can also be written in terms of a struct:
> >> >> >>>
> >> >> >>> contract linkedListNode {
> >> >> >>> X struct {
> >> >> >>> next *X
> >> >> >>> }
> >> >> >>> }
> >> >> >>
> >> >> >>
> >> >> >> In this example taken from the linked document; what is X?
> >> >> >>
> >> >> >>
> >> >> >> On Tuesday, 20 November 2018 05:38:31 UTC+3, Burak Serdar wrote:
> >> >> >>>
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> A while ago I sent an email to this list proposing an
> alternative way
> >> >> >>> to specify contracts using existing types, with a "like" keyword
> to
> >> >> >>> represent contracts on primitives. The idea stirred up some
> >> >> >>> discussion, I got some useful feedback, and eventually, it died
> down.
> >> >> >>> The idea stuck with me though, because it wasn't complete when I
> >> >> >>> proposed it, it had inconsistencies and unresolved problems. It
> turned
> >> >> >>> into this puzzle that I kept working on on the side, I started
> writing
> >> >> >>> a contracts/generics simulator, which I never finished, but it
> allowed
> >> >> >>> me to figure out a way to solve the problems the original idea
> had. So
> >> >> >>> the latest version of that proposal is now here:
> >> >> >>>
> >> >> >>> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> >> >> >>
> >> >> >> --
> >> >> >> 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.
>
--
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.
