[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
Looks like a case for automatic dereferencing!
Which Perl has always stated it would _never_ do.
Well, this could be the time of changes.
-- Johan
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
Looks like a case for automatic dereferencing!
Which Perl has always stated it would _never_ do.
Kinda.
To be honest, Perl does do autoderef in at least two places.
1.
$fh = *FH;
$fh = \*FH
can be used
From rfc 98:
=head2 acceptable coercions
When resolving which method Cfoo() to call in a context CTXT, and there
is no method Cfoo() defined for the context CTXT, Perl will examine
the types listed in C@CTXT::ISA{OVERLOAD_CONTEXTS} for a list
of other contexts
to see if Cfoo() can
[Quoting Chaim Frenkel, on August 20 2000, 00:54, in "Re: RFC 132 (v1) sub"]
Why do you mind having an attribute?
An attribute would
- require the sub to be consequent in what it returns;
- require the sub to be predeclared before it can be used;
- make it unfeasable for methods.
--
"JV" == Johan Vromans [EMAIL PROTECTED] writes:
JV An attribute would
JV - require the sub to be consequent in what it returns;
I can't parse that line.
JV - require the sub to be predeclared before it can be used;
lvalueness seems to be appropropriate.
These two should have different
"JV" == Johan Vromans [EMAIL PROTECTED] writes:
These two should have different actions.
$foo = foo;
foo = $foo;
Perl needs a value for one, and a reference for the other.
JV I'm not sure I understand what you trying to say here. Please explain.
The difference between RHS and LHS.
What about?
sub foo { lreturn ($one, $two, $three); }
foo = (0..10);
or
foo = bar;
The compiler needs to know what foo is returning. The attribute tells
perl evaluate foo to determine the context (i.e. where to put the
dirty laundry) and the goes ahead and does the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: Aug 18, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 132
=head1
[EMAIL PROTECTED] (Randal L. Schwartz) writes:
So is that something we've agreed, that lvalue subs are *always*
scalars? That'd mean we can move on to the various implementation
details. :)
Err, I for one would like to see *any* data types lreturn-able.
If a subroutine can return a list,
Johan Vromans writes:
I think scalars play a super-normal role already. E.g., hashes and
arrays can hold only scalar values. The restriction to scalars may be
a small one, especially when it makes the whole idea of lvalued
subroutines feasible. Without the need for zillions of operator
10 matches
Mail list logo
