(Without expressing an opinion on the topic either way) it appears
to me that theres an issue revolving around how the interface will
be used. Before we continue discussing the details of the interface,
how about agreeing on where and how a proposed interface will be used
at a fairly abstract level. I suspect that that will dictate the form
of the interface (or possibly make it clear that we need two, and
someone may have to compromise if we feel we can really do only one).
Donn
> -----Original Message-----
> From: David Korn [mailto:yyy@xxxxxxxxxxxxxxxx]
> Sent: Monday, August 14, 2000 2:09 PM
> To: yyyyyyyyyyyy@xxxxxxxxxxxxx
> Cc: yyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Re: Re: AI 2000-05-010: proposed interface
>
>
>
> > > If it is true, that no two characters can have the same collation
> > > order, (which I assume is required), then wouldn't ==
> mean that the
> > > strings are equal?
> >
> > Yes.
> >
> > > Clearly this can be written in terms of yours and vica versa,
> > > but this seems more likely to be more efficient to implement.
> > > It could even be done as a table lookup.
> >
> > Speaking from experience, implementing the string
> comparison function
> > in terms of your function is far less efficient. You have
> to look up
> > in various tables and possibly ceate data structures. Also, this is
> > the more consistent interface since there is strcoll().
> >
>
> The use of collation order is in RE's. At compile time of the
> expression, you know the ranges so that colseq() for the endpoints
> would only have to be done once. Thus, a single call to colseq()
> can be used to test to see if a character is in the range.
>
> I believe that it would be a bit more complicated to use with strseq()
> However, I believe that it would require two calls to this
> function to test if a character is in the range, not 1 as
> with colseq().
>
> David Korn
> research!dgk
> yyy@xxxxxxxxxxxxxxxx
>
|