Re: pbr vs multiple returns
Matt Lewis wrote:
>
> Jason Gade wrote:
> >
> > The routine specification tells the user whether the parameter is modified
> > or
> > not. Nothing should be "unexpected". However most routines would not be
> > written
> > to use PBR and probably even fewer library routines.
>
> It might even make sense to make the caller specify pbr, so that both
> the caller and the callee have to agree. That way it's explicit that
> you're allowing and expecting it to change.
>
> Matt
I would definitely agree that PBR shoud be defined by both the callee and
caller. I'm not very convinced that PBR is nessecary though.
Other than convenience and a slight improvement to readability (which is
debatable IMO), can someone please explain how PBR would be useful compared to
multiple return values? It aint clicking for me. Optimization?
Also, regarding multiple return values. What is the purpose of providing an
alternate syntax for multiple return values?
I don't see the purpose of introducing a new syntax to declare that a function
returns multiple values. We can already do that by returning a sequence. All we
need is a syntax for how to assign the members of a returned sequence to multiple
variables.
{err,val} = get("3.14")
Shouldn't that be a viable statement without having to modify how get() works?
In anycase, I would whole heartedly agree with the syntax I demonstrated for
multiple return values. I would rather not be required to use a special syntax to
declared that a function returns multiple values. I don't see much point in it
other than to force the caller to assign the result to multiple variables,
instead of to a sequence if they wanted.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
