Closed Bug 76946 Opened 23 years ago Closed 15 years ago

string lib could do with |startsWith| and |endsWith| functionality

Categories

(Core :: XPCOM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jag+mozbugs, Assigned: jag+mozilla)

References

Details

I've ran into a couple of places where people were doing |!strncmp(str1, str2,
str2len)|. Trying to convert that to string iterators I ended up with something
like |Substring(str1, 0, str2.Length()).Equals(str2)| or
|str2.Equals(Substring(str1, 0, str2.Length())|.

I think this operation is common enough to warrant a specialized |startsWith|,
i.e. something like |str1.startsWith(str2)|. Similar reasoning applies for
|endsWith|, though less often encountered.
Status: NEW → ASSIGNED
Summary: string lib could do with |startsWith| and |endsWith| functionality → [RFE] string lib could do with |startsWith| and |endsWith| functionality
See in bug 60182 my comment of 2001-05-08 11:03 for an implementation.
once we've got this, there is some code in nsPrefMigration.cpp and nsProfile.cpp
(and elsewhere) that can be removed.
My main problem is that non-member functions don't look right, e.g.,

  if ( StartsWith(a, b) )

but I hate cluttering up the string interface with super special purpose routines,

  if ( a.StartsWith(b) )

I'm wondering if I can't do some late resolution magic to make something like
this work

  if ( a == StartOf(b) )

Plainly it's needed, people are doing this operation, though not _frequently_.
It needs some answer, it's just not on my list of immediate priorities
I agree that these should not go on the interface, but think StartsWith(string,
prefix) and EndsWith(string, suffix) are fine.
It looks kinda strange at first, but if something like

  if (StartOf(string) == prefix)

can work, I'd prefer that over

  if (StartsWith(string, prefix))

just for code readability. Given

  if (StartsWith(a, b))

I read that as "if b starts with a", which would be "if prefix starts with
string", which isn't what the code will do.
Here's my current thinking: providing some specialized substring functions can
solve this problem and others, including getting rid of ugly bad |Left|,
|Right|, and |Mid|.  Imagine that (member) |Left| is defined like this

  const nsDependentSubstring Left( PRUint32 aLength ) const;
  const nsDependentSubstring LeftOf( const const_iterator& ) const;
  const nsDependentSubstring LeftOf( const nsDependentSubstring& ) const;

Uses of the _old_ version of |Left| (that wrote into a parameter) could be
replaced like so

  - sourceStr.Left(destStr, N);
  + destStr = sourceStr.Left(N);

The hypothetical |StartsWith| function could be replaced like this

  - if ( sourceStr.StartsWith(pattern) )
  + if ( pattern == sourceStr.Left(pattern.Length()) )

Additionally, when |Find| returns a substring, |LeftOf| and |RightOf| could be
used to manipulate the parts of the string before and after the match.  For
example, you could make a new string that has deleted the matched part of your
source string by saying

  destStr = sourceStr.LeftOf(match) + sourceStr.RightOf(match);

and other interesting combinations.

I think this answer is much more flexible that |StartsWith| etc., but still
answers that problem without a loss of efficiency.
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] string lib could do with |startsWith| and |endsWith| functionality → string lib could do with |startsWith| and |endsWith| functionality
giving up ancient string bugs to the new string owner.  jag, you'll want to sort
through these and see which ones still apply and go with or against the
direction in which you intend strings evolve
Assignee: scc → jaggernaut
Status: ASSIGNED → NEW
Blocks: 446252
QA Contact: scc → string
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.