Re: Named Subroutine return values
On Fri, Feb 24, 2006 at 04:56:40AM +, Luke Palmer wrote:
: On 2/24/06, Damian Conway [EMAIL PROTECTED] wrote:
: No. One of the available TRAITS is Creturns RETTYPE. So you can always
: specify a postfix return type, even without a declarator:
:
: sub data() returns Str {...}
:
: The declarator is only needed if you want to prefix your return type
: (presumably because you're pining for C/C++ ;-):
:
: our Str sub data() {...}
:
: Didn't we decide that:
:
: our Str sub foo() {...}
:
: Was equivalent to:
:
: our sub foo(-- Str) {...}
:
: But not to:
:
: our sub foo() returns Str {...}
:
: ?
:
: Come to think of it, that seems backwards. After all, aren't:
:
: my Foo $x;
: my $x of Foo;
:
: Equivalent?
:
: Come to think of it, it's probably a bad idea to have a distinction at all.
Au contraire, I think it's a good idea in the mindthink of Be strict
in what you emit. Or maybe it's Underpromise and overperform.
The prefix and -- forms advertise a particular promise, but the
routine might actually wish to be pickier than that on what it actually
emits, and rather than casting every return statement to a particular
type, can say returns Str instead.
Say, for instance, you're in a situation where the return type might
be used for a tiebreaker, but you want to reserve that namespace
for yourself. On the other hand, your current implementation is
perhaps TCLishly string oriented. But you want to call out to other
functions that aren't Str filtered. You can declare
sub foo (-- Any) returns Str {
return whatever();
}
and force Str context on whatever() without promising that you're doing
that do everyone else.
Larry
Re: Named Subroutine return values
On Fri, Feb 24, 2006 at 04:56:40AM +, Luke Palmer wrote: : Come to think of it, that seems backwards. After all, aren't: : : my Foo $x; : my $x of Foo; : : Equivalent? Didn't answer this part... If -- and returns are different, than of probably sets the -- type rather than the returns type. Or maybe there's no distinction for non-subs, but it seems nice to associate returns with return. Larry
Named Subroutine return values
According to the revised Synopsis 6, named subroutines can have one of three
forms:
my RETTYPE sub NAME ( PARAMS ) TRAITS {...}# lexical only
our RETTYPE sub NAME ( PARAMS ) TRAITS {...}# also package-scoped
sub NAME ( PARAMS ) TRAITS {...}# same as our
Note that the third possibility here does not include a return type. Does
this imply that if we want to declare a subroutine with a return type we
have to declare it as either a my sub or an our sub?
Joe Gottman
Re: Named Subroutine return values
Joe Gottman asked:
my RETTYPE sub NAME ( PARAMS ) TRAITS {...}# lexical only
our RETTYPE sub NAME ( PARAMS ) TRAITS {...}# also package-scoped
sub NAME ( PARAMS ) TRAITS {...}# same as our
Note that the third possibility here does not include a return type. Does
this imply that if we want to declare a subroutine with a return type we
have to declare it as either a my sub or an our sub?
No. One of the available TRAITS is Creturns RETTYPE. So you can always
specify a postfix return type, even without a declarator:
sub data() returns Str {...}
The declarator is only needed if you want to prefix your return type
(presumably because you're pining for C/C++ ;-):
our Str sub data() {...}
Damian
Re: Named Subroutine return values
On 2/24/06, Damian Conway [EMAIL PROTECTED] wrote:
No. One of the available TRAITS is Creturns RETTYPE. So you can always
specify a postfix return type, even without a declarator:
sub data() returns Str {...}
The declarator is only needed if you want to prefix your return type
(presumably because you're pining for C/C++ ;-):
our Str sub data() {...}
Didn't we decide that:
our Str sub foo() {...}
Was equivalent to:
our sub foo(-- Str) {...}
But not to:
our sub foo() returns Str {...}
?
Come to think of it, that seems backwards. After all, aren't:
my Foo $x;
my $x of Foo;
Equivalent?
Come to think of it, it's probably a bad idea to have a distinction at all.
Luke
