Opened 14 years ago

Closed 13 years ago

#6419 closed enhancement (wontfix)

improve dojo.string.trim()

Reported by: guest Owned by: Adam Peller
Priority: high Milestone: future
Component: String Version: 1.1.0
Keywords: Cc:
Blocked By: Blocking:


Refs #3731.

Actual dojo.string.trim() implementation comes from a Steven Levithan's post.

Steven Levithan has added to his post about trim ( a faster and shorter implementation (the 12th, he calls it trim12). I think dojo.string.trim() should be updated with that implementation.

Change History (4)

comment:1 Changed 14 years ago by wolfram

If there is already movement in dojo.string.trim(), let me suggest another addition, that many of the default trim implementations (i.e. Python) have, it is passing a second parameter of which string to trim, like so:

>>> dojo.string.trim("/path/to/split/", "/")

>>> dojo.string.trim("DELIM what the heck DELIM", "DELIM")
" what the heck "

comment:2 Changed 14 years ago by Adam Peller

Milestone: tbd

I think the addition could cause serious regressions to a carefully method seriously tuned for performance. This should be pursued in a separate ticket.

comment:3 Changed 14 years ago by Adam Peller

Milestone: tbdfuture

I did a quick test in FF3 and found no measurable different with a medium-sized string. More benchmarks would be necessary to see if there's any real improvement elsewhere.

We could pull out the regexp from the loop in the existing implementation (one of the improvements) though that too seems to make no measureable difference. Does the interpreter do something clever, or is it really wasting objects?

comment:4 Changed 13 years ago by Adam Peller

Resolution: wontfix
Status: newclosed

Unless we have some data on this showing a performance improvement, I'm thinking we should leave things as they are. Browsers are beginning to support trim natively anyhow (and as of 1.3 we are using that native method, if available)

Note: See TracTickets for help on using tickets.