On 8/16/06, Ray Denenberg, Library of Congress <[log in to unmask]> wrote:
> From: "Robert Sanderson" <[log in to unmask]>
>
> >  .... we do need at
> > least start:length, where both start and length are positive integers.
>
> You mean   start:end    I hope.
>
> The proposal originally had start:length but was changed to start:end.  I
> assume we don't want to (arbitrarily) change that back. Please let's not,
> unless there is a compelling reason, and I can't find one in this thread.

Sorry, I can't resist ...

man string.h (while there is no substr, its extraction counterparts --
strncpy and friends -- use length)

perldoc -f substr

All examples that I could find of C/C++ libraries implementing substr
use length ( http://www.cs.wisc.edu/condor/classad/c++tut.html )

PHP - http://us2.php.net/substr

SQL - http://www.1keydata.com/sql/sql-substring.html

An example cited to me (either here or in IRC) of why end position
makes sense/was chosen/whatever was that of Python's syntax:

  afield = theline[3:8]

But, see, that's a slice, not a substr.

IHMO, because every language that I've ever had occasion to use, that
supports 'substr' or some variant thereof, uses length as the second
parameter, I hope a reversal will be considered.  And, just to note,
perl, php, and SQL do accept negative numbers for start position,
meaning "starting that many back from the end."  Of course, those are
0-based (as is C, so most implementations of substr for C do the
same), so I'd vote for making start position 0-based as well.

Just my $0.02, and it's worth what you paid for it.  :)

-- 
Mike Rylander
[log in to unmask]
GPLS -- PINES Development
Database Developer
http://open-ils.org