Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
String Manipulation [Feature Request: Harlowe]
I've got an event during my game where the player may learn the gender of another character or continue describing them as an object (reinforcing the sense of inhumanity):
If I could convert a string to lowercase then perhaps that's one way. Or if I could capitalise the first letter easily - that would be more ideal.
If there's a way to already do this that I've missed, that would be great. Or perhaps it could be a feature request as I have a basic workaround already, but some more tools for common occurences like this would be really helpful.
(set: $she to "it")(set: $her to "its")(set: $hers to "its")(set: $She to "It")(set: $Her to "Its")(set: $Hers to "Its")If I could convert a string to lowercase then perhaps that's one way. Or if I could capitalise the first letter easily - that would be more ideal.
If there's a way to already do this that I've missed, that would be great. Or perhaps it could be a feature request as I have a basic workaround already, but some more tools for common occurences like this would be really helpful.
Comments
That being said it is possible to use javascript's built-in String object methods to change the case of text:
Also I must add that their allowance in current Harlowe is solely due to these syntax structures going unused in the interpreter, so it's possible (but not currently anticipated) that JS property-access and JS function call shaped syntax could be used for something else in some future version.
....
WRT basic data manip functions: Harlowe is not naturally an OO language. I decided that from a beginner's perspective, it was confusing having to deal with the subject of a function sometimes being inside the parameters (such as
either(str, str2)) and sometimes being outside (such asstr.slice(2)). So, all of the macros are in the same namespace. This means, though, that I have to be especially careful about naming them: (replace:), for instance, is a macro that applies solely to hooks, and as such can't be used for a string value manipulation macro. (I'm not particularly keen on that name in particular, but reasoned that it'd be more common for most users than programmatic string manipulation would be.)So, that's one of the things I have to concern myself with. The other thing is making sure I'm designing these macros in the most usable way - is
(rewrite: $str, (a:"he", "his", "him"), (a:"they", "their", "them"))good? What if I someday add leftward currying/partials, though - wouldn't(rewrite: "from", "to", $str)be better, insofar as the replacement can then be curried/saved using(set: $theyPronouns to (rewrite: (a:"he", "his", "him"), (a:"they", "their", "them")))and used by e.g.($theyPronouns: "He packed his bags")? (This is just an example - I almost certainly won't add currying in that manner because it would eliminate the error messages for missing arguments.) While I could grant myself a lot of latitude in making breaking changes to the API, I want to avoid having to walk back deployed designs as much as possible.I understand the necessity of getting these basic utilities out, and you might think the few things I've added already, such as
(count:)and(substring:)have already set the template for such macros, but nevertheless I'm still being cautious about adding them without thorough contemplation.I admire the effort your putting into getting it right and my only advice is to let languages that came before yours help guide you as yours is not the first to be designed with non-programmers in mind.