If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Provide inline EqualsIgnoreCase and CompareIgnoreCase

RESOLVED WORKSFORME

Status

()

Core
String
--
enhancement
RESOLVED WORKSFORME
14 years ago
6 years ago

People

(Reporter: Darin Fisher, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

14 years ago
I really think we should provide inline wrappers around Equals(...
nsCaseInsensitive?StringComparator) and Compare to ease coding.  I can't stand
having to type so many characters to get case insensitive comparsion, and I'd
imagine others would agree with me.  Anyways, it is really easy to provide
inline wrappers, that don't in any way break the rule that xpcom shouldn't have
to depend on unicharutils, so why not?  I'll attach a concept patch shortly...
(Reporter)

Comment 1

14 years ago
Created attachment 127467 [details] [diff] [review]
v0 concept patch
(Reporter)

Updated

14 years ago
Attachment #127467 - Flags: superreview?(dbaron)
Attachment #127467 - Flags: review?(jaggernaut)
Did you try compiling this in a gcc debug build?
(Reporter)

Comment 3

14 years ago
does gcc 3.1 20020420 (osx 10.2) count? ;)

what are your concerns about gcc?

Comment 4

14 years ago
Uhm... nsAString is frozen, so you can't add the member functions. And won't
lack of nsAString::EqualsIgnoreCase() when unicharutils isn't linked in give you
build errors?
(Reporter)

Comment 5

14 years ago
>Uhm... nsAString is frozen, so you can't add the member functions. And won't
>lack of nsAString::EqualsIgnoreCase() when unicharutils isn't linked in give you
>build errors?

this doesn't break binary compatibility in any way shape or form.  the fact that
the interface is frozen doesn't prevent us from adding inline helper functions.

you'd only get linker errors if you tried to use nsAString::EqualsIgnoreCase
without including nsUnicharUtils.h, which is desirable i think.
Comment on attachment 127467 [details] [diff] [review]
v0 concept patch

Is this still relevant?  If so, could you provide an up-to-date patch?
Attachment #127467 - Flags: superreview?(dbaron)
(Reporter)

Comment 7

14 years ago
Comment on attachment 127467 [details] [diff] [review]
v0 concept patch

yeah, i think this patch is still relevant.  i'll update it.
Attachment #127467 - Attachment is obsolete: true
Attachment #127467 - Flags: review?(jag)
(Reporter)

Updated

14 years ago
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha
Hmm, I guestion the need for these to be inline... Having those methods is nice,
but do they need to be inlined, really?
(Reporter)

Comment 9

14 years ago
good point.  they don't need to be inlined.  since callers have to link to
libunicharutil_s.a anyways, we could just implement nsAString::EqualsIgnoreCase
in there.
(Reporter)

Updated

13 years ago
Keywords: helpwanted
Target Milestone: mozilla1.8alpha1 → Future
(Reporter)

Updated

11 years ago
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: scc → string
Target Milestone: Future → ---

Comment 10

6 years ago
I see some EqualsIgnoreCase functions in some string classes
(1. http://mxr.mozilla.org/mozilla-central/source/xpcom/string/src/nsStringObsolete.cpp#985 
2. http://mxr.mozilla.org/mozilla-central/source/xpcom/string/public/nsTString.h#258)

Moreover I see nsCaseInsensitiveCStringComparator class which has case insensitive comparator.
http://mxr.mozilla.org/mozilla-central/source/xpcom/string/public/nsAString.h#77

Do we still needs this for some other string classes like nsTSubString? If no, then we should close this bug as Resolved/WorksForMe.

Comment 11

6 years ago
Yeah, we fixed this a long time ago.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.