LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  August 2006

ZNG August 2006

Subject:

Re: substring proposal

From:

Robert Sanderson <[log in to unmask]>

Reply-To:

SRU (Search and Retrieve Via URL) Implementors

Date:

Mon, 7 Aug 2006 12:53:57 +0100

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (44 lines)

>Referring back to the original email:
> > substring="-2:0"  -- the last two characters  // not possible currently
> > substring="0:0"   -- the last character
>
>Shouldn't substring="-2:0" be the last *three* characters, as
>substring="-1:0" would be the last two?

Yes.

The fault is mine -- I'm a python programmer at heart, and the python
syntax is very similar:

string[start:end]
0 based, where negatives count backwards, end is *not* inclusive and
start or end omitted means start or end of the string.

So in python,  "string"[-2:] == "ng"

The other issue with my poor examples was that I was also considering
not having 0 at all, and the last character of the string would then be
-1, as the first character of the string would be 1, but then thought
that changing as little of the current proposal as needed would be
better.

So in that version, string[-2:-1] would be the final two characters of
the string.  If that's easier to use (it is for me, at least) then we
should change it to that instead.  However -0 and negatives being
special in end, and not allowed in start is IMO worse than either of the
above.

That said, I also don't expect that substring will be frequently
implemented or frequently used to its full capacity.  However I do still
believe it belongs in the cql context set, as it's useful for many
different types of data, in the same way that regular expression
searching is.

>The proposed substring function is really many functions in
>disguise. I reckon it is at least five distinct functions:

At least.  But we don't really want 5 or more relation modifiers that
each cover a small part of the functionality of substrings, do we?

Rob

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager