I think there is no really big reason to make a special tuple type for
return values. The extra burden comes in specifying the type and wrapping
the list in curly brackets, and predefining the elements in a type struct
declaration. I am writing a dense binary tree implementation (dense as in
not sparse like all previously invented BST's) and I have defined a
'cursor' structure which very conveniently can be used as both parameter
and return value, and has made my code 1000x more readable and
maintainable. Here is some snippets from this code:
type Cursor struct {
Index Index
Row Row
Err error
}
An example where I am just passing things through:
func (b *Bast) Parent(c Cursor) Cursor {
if c.Index == 0 {
c.Err = errors.New("No parent from the root")
return c
}
c.Row--
c.Index = c.Index>>1 - (c.Index+1)%2
c.Err = nil
return c
}
And here is an example where I named the variable in the function so it
creates a new instance that I can work on separately to the input value:
func (b *Bast) Find(d Data) (c Cursor) {
for notfound := true; notfound && c.Err == nil; {
if b.Store[c.Index] == d {
return c
}
if b.IsLeft(d, c) {
c = b.LeftChild(c)
} else {
c = b.RightChild(c)
}
if c.IsOutside(b) || b.Store[c.Index].IsEmpty() {
c.Err = errors.New("Did not find data in tree")
}
}
return c
}
On Saturday, 21 November 2009 03:23:43 UTC+2, ziyu_huang wrote:
>
> I like multiple return, when language support it, tuple is meaningless
> to me.
> Why add complex syntax when there already have simple one ?
> A simple struct can do the same thing if you insist to ..
>
> type ATuple {
> rv1 int;
> rv2 int;
> rv3 string;
> }
>
> func tuple_return_func() {
> a, b int;
> ...
> return ATuple { a, b, "some string"};
> }
>
> ret := tuple_return_func();
>
>
>
> On 11月21日, 上午12時47分, Ben Tilly <[email protected]> wrote:
> > On Fri, Nov 20, 2009 at 7:36 AM, Joseph Stewart<[email protected]>
> wrote:
> >
> > [...]
> >
> > > Being a Lua user, I've grown accustom to multiple return values... I'd
> > > respectfully like this feature to remain.
> >
> > Ruby demonstrates that there is no contradiction. If you add in the
> > ability to flatten a tuple, or decide when to gather several things
> > into a tuple, then the two features co-exist perfectly
> >
> > Inventing some syntax:
> >
> > // explicit declaration
> > type SomeTuple [string, int] tuple;
> >
> > // Interaction with multiple returns
> > myTuple := [ function_returning_multiple_values() ];
> > this, that := @myTuple;
> >
> > Cheers,
> > Ben
>
--
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.
