First, some context:

When you call list.evaluateItem, it evaluates the square and curly blocks of course, but it also removes backslashes that were before any square or curly blocks. Backslashes are used to tell the Perchance engine that a square or curly bracket should be interpreted ‘literally’ - i.e. not as a character with a special meaning.

So, for example if we call evaluateItem on a list item like this: {1|2|3} \[cool\] the output will be something like 2 [cool]. If we didn’t put the backslash before the square bracket, the Perchance engine would look for a variable/list called “cool” and if it didn’t find one, you’d get an error. The backslash says “treat this as a normal/literal square bracket - not a fancy Perchance thing”.

Now to the point of this post:

Notice how in the above example of using evaluateItem on a list, the output (2 [cool]) has the backslashes removed? As previously mentioned, that is the correct/desired behavior. But I just found a bug where if you call evaluateItem on a string like {1|2|3} \[cool\] it would output 2 \[cool\] instead of 2 [cool].

I’ve just fixed this bug - so the backslashes are now removed (just like when using evaluateItem on lists and list items), but I’ve made it so the bugfix is only applied when you next save your generator - just in case there are any issues with the fix. So please go ahead and save your generator, and if you run into any issues, even if you fixed them, please let me know in the comments. Any examples of issues will help me build an understanding of the effect of this change.

Thanks!

  • BluePower@sh.itjust.worksEnglish
    1·
    4 months ago

    Another great use of evaluateItem (from my experience) is that it helps evaluate strings containing arbitrary code into proper output behind-the-scenes before modifying them with other properties or functions. For example, running ["[conjugate(verb).gerund] [adjective.pluralForm]"] outputs as expected, a phrase consisting of a gerund verb and a pluralized adjective word. The Perchance engine evaluates the unevaluated string right away after any modifications (for example, through titleCase) were made. And so, running ["[conjugate(verb).gerund] [adjective.pluralForm]".titleCase] will result in a mixed undefined or (syntax error) output (e.g. intending undefined) because it converted the unevaluated string (which is the Perchance code) into title case before it was evaluated, and results in an unwanted output.

    But prepending evaluateItem right before any modification would do the opposite - it evaluates the string before any modifications was made. Using that, running ["[conjugate(verb).gerund] [adjective.pluralForm]".evaluateItem.titleCase] would output a properly title cased phrase in that same format because the Perchance code inside the string is evaluated before the final output was eventually made title cased.