ID:1872220
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
begins_with(string,substr)

returns true if the string begins with the complete substr, false otherwise

ends_with(string,substr)

returns true if the string ends with the complete substr, false otherwise

replace_text(string,find,replace)

searches a string and replaces any instance of find with replace. Returns the modified string.

tokenize(string,separator)

returns a list of strings by splitting the supplied string at any case of the string sperator

trim_whitespace(string)

removes whitespace from both ends of a string

This is just to name a few functions that are desperately missing. Dealing with strings in DM is absolutely horrible, and it has been for years. It's better than it was, but the more I work in mainstream languages the more I realize that string handling was never really completed in DM.
A big question is, how much speed do you need out of these and to what end? All of these functions are easily implemented in soft code, although obviously they won't be as fast as anything built-in. I'm hesitant to go too far overboard adding new built-in procs, though.
Yeah, I've been bugging Lummox about this for literally over a decade now. BYOND doesn't even use the standard string library in its C++, which is bonkers.

For replace(), I've actually found a sneaky (and somewhat quick) solution by passing text to SQLite's replace() function, it's not a LOT faster than soft-code solutions but it does seem to handle giant strings better.
The string functions I really wish DM had more than anything are equivalents to strspn() and strcspn().
I've already got all of these plus most of a JSON-to-datum parser and datum-to-JSON parser in the works in softcode.

String handling in DM is just plain painful. Moreso than any other language I've ever worked with. It's not really an issue of "can it be done", so much as these are things that programmers have come to expect.

Honestly, if you don't want to clutter the syntax it might be high time to investigate using global objects as a sort of pseudo module, Lummox.
In response to Lummox JR
The problem is that soft-code solutions tend to choke on larger and more complex strings, not to mention overhead caused by various functions calling multiple procs to accomplish their goal. Plus you have no consistency in string handling across the libraries that do provide it all claiming to be just that tiny bit faster than the one before it.

The only real solid string handling method I've ever come across in soft-code is using STL through a DLL which works fantastically but obviously comes with the whole security issue and porting to a Linux SO file (which is fairly easy with basic text handling, but tedious nonetheless)
I've always wished BYOND had a built-in string datum like the one I made for my StringHandler library. Most OOP languages I've used take a similar route. Would be REALLY cool if it was mutable and all that jazz too.
I agree. I don't like polluting the global namespace with functions, but BYOND doesn't support namespaces, so really exposing a pseudo-datum to the global scope is really the best we can do with DM's syntax.
I've strongly considered the datum approach for a while. There are a lot of questionable aspects to it, but it might be workable. The interesting thing of course would be that a datum would act like a mutable string without actually being one. (The downside: Good gads, it's amazing how many places check for a string value.)
Actually, I wasn't talking about making strings a datum, but rather treating a datum like a namespace for storing global functions. Basically exposing a singleton datum to the global namespace.

For instance, in most programming languages, floor() isn't a global function. It belongs to the Math namespace:

Math.floor()
In response to Ter13
Ter13 wrote:
Actually, I wasn't talking about making strings a datum, but rather treating a datum like a namespace for storing global functions. Basically exposing a singleton datum to the global namespace.

It's kind of six of one, half dozen of the other, I expect.
+1 To this feature.