Email List: Xaustin-group-lX
[All Lists]

Re: AI 2000-05-010: proposed interface

To: yyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: AI 2000-05-010: proposed interface
From: Antoine Leca <yyyyyyyyyyyy@xxxxxxxxxx>
Date: Thu, 17 Aug 2000 16:40:27 +0200
Organization: RENAULT (mais cette contribution est personnelle et n'engage pas RENAULT)
References: <309F4FC4705DC844987051A517E9E39BF5BDC9@red-pt-02.redmond.corp.microsoft.com>
Donn Terry wrote:
> 
> (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).

I do not know if I am on the right track here. In fact, I expect advises.

One of the problem I have with the current interface(s) (I mean, strcoll,
regex et alii), is that I am unable to use them to do "partial" collation,
e.g. collation disregarding the case (but taking in account the diacritics
and of course the current locale). An useful application could to use a
stable sort (so _not_ using qsort()), but disregarding case differences.
So if I have MacArthur < Macarthur < MacArthur as input, I would like to
keep this order.

Another application is to create indices grouped by the first collation
elements (i.e. in Traditional Spanish, all words beginning with ch are
grouped together, perhaps headed with a proeminent -CH-). Again, it
appears to me this is not easy to do with the current API.


Of course, a solution is (and it had been used for a while), to design
ad hoc libraries for just this kind of uses (about that, I note that
only a few of these libraries relies on the localedef mechanism, while
it may be perfectly adequate; but that's an aside). After all, the Standard
library is not intended to cover _all_ needs, so this is a perfectly
correct answer.
My point is rather to ask if the new API intends to cover these needs,
or if it needs to, or if it does not have to.

 
Antoine

<Prev in Thread] Current Thread [Next in Thread>