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.