> > Perhaps .size for number-of-elements and .length for length-of-string > > would work? > <sarcasm> > This would just cause them to Think About Things A Different But > Equally Wrong Way: as assembly language objects whose SIZE in bytes is > the determining component of their existence. > </sarcasm>
I am happy to see other suggestions for the names. The ones I mentioned were simply spur-of-the-moment ideas, which I agree have problems. > Seriously, if they're smart enough to run a text editor, I think it's > safe to say that they can handle the conceptual difference between the > "length" (mins:secs) of a video, and the "length" (feet:inches) of the > mag-tape that encodes the video. People deal with different inherent > units all the time in the real world -- some of them even remember to > carry the units through their equations when they're doing math. Let's > give some credit to the audience at large. With respect, I have plenty of evidence to suggest that programming students *won't* handle the difference (many years of teaching first- and second-year programming at University). I see students at all levels saying things like: char *dupString = malloc(sizeof oldString + 1); when they mean: char *dupString = malloc(strlen(oldString) + 1); (Actually, that's a good argument against using "size" to mean number-of-elements of Perl arrays, isn't it?) Perhaps you are talking about experienced programmers rather than students. In that case, I agree with you. But everybody has to learn Perl once. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] "Long and wide, eternity from side to side, lead me through the rapids, guide me to the shore. There's a place that's far beyond this time and space, when each of us comes face to face with something more." - _Siren Song_, Alan Parsons
