On Fri, May 17, 2002 at 05:40:30PM -0600, Luke Palmer wrote:
Back to from where this arose, however, I think LAST (and BETWEEN, if
it will exist) should probably be PRE blocks. This is the only way it
could be consistently possible to implement. It wouldn't make any
sense to have it a PRE
On 16 May 2002, Aaron Sherman wrote:
On Thu, 2002-05-16 at 16:13, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
You might not be able to REASONABLY get a length, so you return
undef. In your documentation, you advise users not to take the length,
but just dive
On Thursday 16 May 2002 01:13 pm, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
You might not be able to REASONABLY get a length, so you return
undef. In your documentation, you advise users not to take the length,
but just dive right in and fetch the element you want,
On Thu, 2002-05-16 at 16:13, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
You might not be able to REASONABLY get a length, so you return
undef. In your documentation, you advise users not to take the length,
but just dive right in and fetch the element you want,
--
On Thu, 16 May 2002 12:36:42
Miko O'Sullivan wrote:
SUMMARY
Arrays should always have known lengths because that's what arrays do. This
requirement is enforced culturally, not programmatically.
I totally agree that this should be enforced culturally. I think that the way a tied
On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote:
From: David Whipp [EMAIL PROTECTED]
It it too much to ask, of the creator of a tied array, to implement
their code in such a way that *reading* an element of that array
does not have significant side-effects?
Actually, I think that
Aaron Sherman writes:
: Should a tied and/or lazy array be forced to present a length on demand,
: or can length return undef on indeterminate arrays?
An array implementation can return anything it jolly well pleases, but
I'd say undef would be a reasonable thing to return if the length is
From: David Whipp [EMAIL PROTECTED]
It it too much to ask, of the creator of a tied array, to implement
their code in such a way that *reading* an element of that array
does not have significant side-effects?
Actually, I think that *is* a significant imposition. The whole point of
tied arrays
In a message dated Sun, 12 May 2002, Miko O'Sullivan writes:
From: David Whipp [EMAIL PROTECTED]
It it too much to ask, of the creator of a tied array, to implement
their code in such a way that *reading* an element of that array
does not have significant side-effects?
Actually, I think
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do look-ahead
here. we don't guarantee order of evaluation
The implication is that we can only provide advanced PRE_LAST
style blocks (or their equiv.) on the Cforeach loop. The fact
that they are impossible on the Cwhile loop should not
constrain our thinking for the Cforeach loop.
Just checking here: is PRE_LAST a separate and non-mutually
Miko O'Sullivan wrote:
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept from LAST? I.e., would this make sense:
foreach arr - $i {
PRE_LAST {print before last loop\n}
LAST {print after last loop\n}
print $i\n;
}
If so, wouldn't
On Thu, 2002-05-09 at 13:22, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do
On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
Not exactly unknown. It's just that, in a few cases, their values may
have changed by the time the LAST block is executed.
And I think
On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
Not exactly unknown. It's just that, in a few cases, their values may
15 matches
Mail list logo
