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.
