mutable strings, just for convenience

ID:1358756
 
Aug 21 2013, 9:03 am (Edited on Aug 21 2013, 11:55 am)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Considering DM is written in C++ and C++'s std::string supports operations for directly altering the state of a string, I think the addition of a mutable string datum - StringBuilder or StringBuffer, perhaps? - would be nice. Currently, strings in DM are immutable, and thus cannot efficiently do repeated string operations such as concatenating, splitting text, reversing strings, etc, without allocating some memory, and it would make problems such as these(http://www.byond.com/forum/?post=105170&hl=string%20memory, http://www.byond.com/forum/?post=195101&hl=string%20memory, http://www.byond.com/ forum/?post=1315764&hl=string#comment5450384 ) trivial.

EDIT: An example.
var StringBuffer/foo

//  Create a new mutable string
foo = new("Hello, world!")

//  Operations that can be performed on the string, either through getters/setters or operator overloading
foo + someString
foo.add(someString)

//  Checks if the string buffer is empty
foo.empty()

//  Clears the string buffer.
foo.clear()

//  Self-explanatory.
foo.length() or length(foo)
Aug 21 2013, 9:46 am
This fits in pretty well with Tom's idea that it'd be nice to have a datum-like interface to strings, such as a /text datum. (The only significant downside: instructions that expect strings, of which there are many, will need to be adjusted.) There's really no reason we can't tie a StringEditor to a special datum like we do with icons, so this is something I'll keep in mind.
Aug 21 2013, 10:49 am
I've been a fan of a string datum for a long time now.

http://www.byond.com/developer/Nadrew/StringHandler

I would have preferred to use the /String datum alone without the helper procs, but unlike giving datums variables like 'icon' and 'icon_state' and having things handle those as expected, giving a datum a 'name' variable doesn't allow the contents of that variable to be displayed like it would be for an /atom when doing a simple

var/String/my_string = new("Hello world")
world << my_string


Without making it an /atom and giving it a bunch of overhead that simply didn't work, so I had to use an ugly 'my_string.text' workaround, which didn't sit so well with me for general use. The helper procs do all the messy work for you due to the need to work around things like that.

Having this built-in would be awesome, especially with how efficient std::string is for string handling. I had a library that used a DLL/SO file to call std::string functions and it blew all of the DM-made solutions out of the water as far as speed on larger strings went. Too much security hassle putting it in a DLL though.
Aug 21 2013, 12:18 pm
We don't use STL, so std::string is moot. We use a string buffer of our own.

The more I look at this, though, the more I realize a lot of our text routines are geared around creating new string objects, not so much working with a buffer. Might be on the iffy side to do this with a buffer, but doing it with an internal string is at least pretty doable.

At the moment I'm fixing up some inconsistencies with the /icon datum because that relates to how I'll handle /matrix (and possibly /text, etc.). For instance, /icon + /icon didn't work. The /icon datum has an icon var that is either an internal object or a cache reference, and the internal object could handle these operators just fine--but nobody accesses it directly for some pretty obvious reasons.
Sep 17 2013, 3:51 pm
I'm not sure if this is related or not, but it would be nice if the "in" keyword/operator worked with text strings.

For example:
if("a" in "apple")//would return true.

This would be far more simple than using findtextEx(). It works on lists and numbers, so why not strings? This would also allow other things, like directly looping through each character in a string. That means there would be almost no need for things like text2list().

Also, you could specify a negative "step" to go backwards! I think "to" could also be used, but that is a more complex issue. I think it could be used for some kind of extremely fast sorting.

Would this require mutable strings as a prerequisite, or is it a whole other issue?
Sep 18 2013, 12:37 am
Given what you've demonstrated is syntactic sugar over an operation that doesn't alter the string, I'd say it's a different issue, yes.
Jan 17 2014, 3:49 am
Any word on this?
Jan 17 2014, 5:52 am
Would it be plausible to pass each character of the string into a list at a seperate index, then alter that index of the list. Thus, altering the string when you load the list back to the string?
Jan 17 2014, 6:52 am
You can already do that via soft-code. Though Python's strings aren't mutable, you could alter a string as if it were a list(you still have to create a new string), which is probably what I think you meant. My suggestion is different, though - I'm proposing a method to directly alter the state of a string without creating a new one.
// What you're suggesting(notice how you have to create a new string):
var/string = "Hello, world"
var/newString = string[1:5] // newString now contains "Hello"
src << newString

// What I'm suggesting:
var/string = "Hello, world"
string[1] = "M"
src << string // Outputs "Mello, world"
Jan 18 2014, 1:21 pm
If I could get mutable strings, negative offsets, and have a string that is treated like a chararray, I'd be so happy.
Jan 18 2014, 8:07 pm
^ Seconded
Aug 15 2016, 6:11 pm
Considering that we now have mutable appearances, it'd be great to have something like a /mutable_string...