Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : > Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about expression.
| :
| : [EMAIL PROTECTED] returns the *number of elements*, not the index of the
last
| : element plus one. It should not be used for index math.
| :
| : There are cases where we should write @foo.last + 1, even though the
| : result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
| : cases where we should write @foo - 1, even though the result will be the
| : same as that of @foo.last.
| :
| : That almost all arrays range from 0..i is no reason to write bad code.
| :
| : > Maybe someone doing
| : > for ([EMAIL PROTECTED])->$i { say @foo[$i] }
| :
| : That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
| : latter.
|
| I don't think that's a big problem. Formal arrays are allowed to view
| all incoming array parameters as 0-based even if created elsewhere as
| non-0-based arrays. Forcing everyone to use the same circumlocutions
| because someone somewhere *might* use a non-0-based view of their
| arrays is just falling back into one of those magical action at a
| distance traps, I think. A non-0-based view is fine in a particular
| lexical scope, but it shouldn't leak out.
|
| Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
| scope.
What about array with holes as supported by Parrot?
Does .elems return the number of elements with or without
the holes?
Does iterating over the array iterates over the holes as well?
That would sound inefficient to do that over a mostly empty array.
Related question, Is there a way to get a list of iterators
that iterate only over the non-holey parts of an array?
--
cognominal stef
|
| Larry
|
