Closed Dunbaratu closed 9 years ago
I Concur, lets do it! :)
I'm thinking this might be added to the 0.15 punch list because of how iterating over parts requires this check:
if (SomePart:Name = "distometer100x") { stuff. }
And that check is currently dependant on getting the capitalization and spelling exactly right because we don't have ToUpper and ToLower and StartsWith() and EndsWith() for the script to use.
Embedding chars inside quotes:
// ---------- 3 different ideas for how to do it: -----------
//embedded, with backslash or other commonly used encoding method: SET newString to "This string has \"quoted text\" in it.". SET newString to "This string has *quoted text* in it.".
//provide some constant built-in variables for some special chars like DQUOTE: SET newString to "This string has " + DQUOTE + "quoted text" + DQUOTE + "in it.".
//provide function to convert number code to character: SET newString to "This string has " + CHR(42) + "quoted text" + CHR(42) + "in it.".
I prefer escape sequences (\n, \, \" etc):
@Dunbaratu I remember you asking something like this: "where should we convert strings to string wrapper object?". My answer is: in the Stack.Push because this way there will be less places where you can forget to do something important.
Another option is to wrap up everything and allow only objects of our wrapper class to be pushed into the stack.
Is it forgotten? 0.17 is released and we still without string functions.
It is done
Lots of people have asked for string manipulator operations. My suggested solution is to make a new subclass of kos.Safe.Encapsulation.Structure, which contains inside it one single C# string and NO other data (having no other data is important for a reason I'll get to below). It then wraps all the string manipulator methods we feel like exposing to the users, and might have a lot of very short code routines like so:
This sounds very simple and straightforward. (I'd rather just subclass C#'s string, but it's sealed so you can't.) But it does have a few consequences elsewhere through the code - one example is that it means now the ML code will need to know to peek inside the wrapper class to get the actual string to store in the ML file (which only stores primitives, not structures, which is the reason it's important that this wrapper class only contain the inner string data and nothing else - so it can be recreated from a vanilla string stored in the ML file). Another example is that the compiler needs to know to create an object of this new type when it sees a quoted string in kOS script.
It may help to also fix issue #253, as it would present a way for the system to distinguish user strings and internally made identifier strings that doesn't require using a leading "$" character. User strings would all be inside this wrapper and identifier strings wouldn't.