Re: NSPredicate bug (Re: Using code from Cocotron)

[Yen-Ju Chen]

On 6/11/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Yen-Ju Chen wrote:
> > On 6/9/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> >>
> >> There are plenty of other problems with predicates that your tests
> >> uncovered. For example we don't support "==", but have "=". Which of
> >> them should we have? Both?
>
> Fixed
>
> >> Also the "IN" operator will only work for strings, not for a set and an
> >> element.
>
> Fixed
>
> >> Handling of "BETWEEN" is completely missing and the parsing of all key
> >> words failed at the end of the string.
> >>
> Fixed
>
> >> I tried to fix some of this, but it requires a lot more work.
> >
> >  Thanx again. I intentionally pick less-used cases for testing
> >  because I believe GNUstep can handle the common ones.
> >  One thing I notice is that with '==' (or '=' for GNUstep),
> >  you cannot specify the case-insensitive ([c]).
>
> Fixed or did I get you wrong and the GNUstep behaviour matched the one
> from Apple?

 Apple does not allow '==[c]'. So I have to use 'MATCHES[c]' for
case-insensitive,
 but due to the regex, MATCHES is not implemented in GNUstep.
 So I have no away to do case-insensitive full string comparison on GNUstep
 excepting using a combination of 'BEGIN[c]', 'IN[c]' and 'END[c]' for that.
 It is just less convenient.
 Maybe for current situation, you can implement MATCHES as simple
full string comparison ?
 It is the same as regex without all the special symbol (*, ?, [, ]).

> >  So I have to use 'MATCHES[c]'. But 'MATCHES' use regex,
> >  which I think is too much if I only want to do case-insensitive
> > comparison.
>
> Regular expressions are still missing in GNUstep. With all these fixes
> only the tests that include %d and the one with matches still fail. But
> don't erxpect any further progress here. We need Richard to look at the
> %d problem.

 Thanx. I will try again later.

 Yen-Ju

> Cheers,
> Fred