On 11/17/2002 1:11 AM, Dave Storrs wrote:
Arrays know how to manage their own size; they will grow and shrink as needed when you add or remove elements. You never need to worry about whether an array has enough space to hold the number of elements you are about to insert.
Reference to fixed-size lists, where this isn't true?
(***)
Examples of arrays (usage): @foo = (1, 2,3); # create/init an array
Clear, consistant formatting: "(1, 2, 3);" -- I know, just a typo.
@foo[2]; # fetch last element
Should also give the value in comment, or better, write as text/test.
@foo[-1]; # fetch last element
Sm.
Should we note here that this also has the value of undef? I would, but with a reference, not an explination.undef @foo; # destroy array, free associated memory, # and decrement reference count on each # value
Also, I'd reorder this:
1) Creating arrays
2) Accessing parts of arrays
3) name/container/values distinction
4) Detailed defintion of arrays
But we're getting into documentation, not defintion. The defintion should be short and simple, and have lots of references. (The things you're refering to mostly won't exist yet, but that's OK.)
If at all possible, I think it would be a very good thing if we could get away from the array/list distinction, at least with those terms. (Finding better terms is a p6d issue, getting rid of it is a p6l issue.) In purticuar, /there is no such thing as a list in scalar context/. There is mearly an application of the scalar comma operator, and spacing that makes it look like a list. The context propigation rules say that there is no way for a list in scalar context to happen. The documentation shouldn't say things like a list returns it's last element whereas an array returns it's size, because it simply ain't so, and causes confusion. (I'd write an RFC suggesting that the scalar comma op dies, but it's too late, and I'm sure somebody already did. Anyway, that's a p6l thing too.)(**) There needs to be a point here explaining the difference between "list of literals" and "literal list" (and the same for arrays), but I find that I don't understand it well enough myself to explain it.
-=- James Mastros